What I Learnt About Engineering Management
I learnt a lot about engineering management at my startup, Futurecam, and at a few startups I advise:
⦿ Engineering management at a startup depends on personal relationships, unlike at a big company. You need to almost become friends with people you manage. Western ideas like separation between work and home don’t always apply. You need to know people well, what they like, their family situation, and so on.
⦿ At the same time, you need to maintain the right distance from people to manage them well. You’re their manager. You should be friendly with them, but not too friendly. If you have to take action against them, you should, because you’re their manager first and foremost.
⦿ Different people have different psychologies, come from different backgrounds, and are motivated by different things. You need to understand each person to manage well. Otherwise, he may not accept your directions, because they’re not taking him in a direction he wants to go, or speaking to who he is. Management is customised, not one-size-fits-all.
⦿ Having a plan and communicating it creates confidence in people about you.
⦿ Being a manager means giving up your personal productivity and the sense of satisfaction that comes from personal accomplishments, for team productivity and taking pride in the team’s accomplishments. You’re a force multiplier, like a lever.
⦿ As a manager, if the team does well, you should take credit, and if your team does badly, you again need to take responsibility. The buck stops with you.
⦿ As a manager, you should do work in an individual capacity one day a week at least. For an engineering manager, that’s coding. For a sales manager, make sales calls. Reviewing other people’s work like code reviews, architecture reviews, design discussions and estimating work doesn’t count as doing work yourself. And if you don’t do work yourself, you’ll lose touch with it, and your input won’t be helpful after a while. You’ll become a pointy-haired boss. That’s not good for the company, or for you.
⦿ As a manager, you should put in place team practices like weekly cycles (or sprints), code reviews, daily standups, etc. Some of these may happen every day, and others rarely, like milestone planning or retrospectives. But all these practices are important.
⦿ As a manager, you play an important role in deciding what the team works on, and what it doesn’t. The second part is critical. Choosing not to work on something is a powerful lever, freeing up both time and mental space for things you should be doing. In any case, setting the tone for the team (“this quarter we’re working on validating that this product is useful”) is a critical function you perform. Otherwise, you’ll have an aimless team.
⦿ As an engineering manager, you balance speed, code quality, UX quality, and business goals.
⦿ As an engineering manager, you solve problems in multiple domains: tech, people, UX and business.
⦿ Communicate expectations to subordinates up front, not after the fact in the form of blame.
⦿ Give as much autonomy as possible, stepping in only when needed, rather than trying to control and micromanage everything. Default to permissive.
⦿ Context over control: Give people the context they need to decide independently.
⦿ Create a sense of psychological safety, that it’s okay to occasionally fail. Otherwise, people won’t try anything, and the team will fail — in a worse way.
⦿ Respect people’s work-life balance and don’t ask them to work more than 40 hours.
⦿ At the same time, if people have a problem preventing them from being productive, whether work-related or personal, they should discuss it with you, their manager, proactively, rather than Don’t try to hide problems hoping no one will notice. Nobody is 100% productive. We all have some weeks where we’re unproductive. After all, we’re humans, not machines. That’s perfectly fine, but let’s be open about it.
⦿ I expect people to speak up if they disagree, or have something else in mind, or prefer a different way of doing things. I don’t work well with people who disagree but keep it within themselves. The team works best when everyone offers what they have. I can’t read people’s minds.
⦿ If I say no to your idea, it often means “not now”. It doesn’t mean your idea is bad. All decisions are temporary.
⦿ Help people learn new skills. Don’t hold them back thinking that someone is not qualified to do something. I helped an engineer learn marketing, and he became better at it than anyone else in the team.
⦿ Anger is a tool you should use rarely, only when you articulated a clear principle (“run the tests before committing and pushing”) and it’s missed multiple times by the same person. If you overuse anger, it loses its potency, and you’ll be a jerk, too.
⦿ Encourage people to say what needs to be said, even if it’s blunt, like “our product sucks”. If we feel that way, there must be users who feel that way, too, and being open to the possibility that there are problems is the first step to fixing them. Shooting the messenger and burying our heads in the sand may make us feel better in the moment, but won’t result in a better product.
⦿ Sometimes you’ll have people who keep pointing out problems or objecting to proposed courses of action. Tell them to suggest a course of action. Because if we don’t, nobody else will give one to us on a platter.
⦿ As a manager, you should have clarity of thinking and communication. You can’t lead a team if you’re unclear yourself, or if you’re clear in your own mind but can’t get across.
⦿ As a manager, you should evaluate how well each person is doing overall, what they do well, what they need to do better at their current level. And what they can do better to get to the next level. You should help people grow in their careers. Define personal milestones for different time periods like a quarter, year and two years.
⦿ As a manager, you create a team out of a set of people, by putting in place a process, and creating a feeling of we’re in it together.
⦿ As a manager, you should balance each person’s individual productivity with being there when others need him.
⦿ As a manager, you have to deal with poor performers.
⦿ I expect everyone to take responsibility, and own whatever they do.
⦿ When in a discussion, seek first to understand, and only then to be understood.
⦿ Be inclusive: listen to everyone’s point of view. But then one person should make the decision. That can be you, or if it’s a smaller decision, delegated down, but in either case, it can’t be a group decision. Group decisions are watered-down decisions, and if everyone is responsible, no one is.
⦿ Be open to discussions, not arguments: as long as new information or perspectives are being presented, it’s fine to continue discussing. Information can be objective, like one option having a feature the other doesn’t. Or it can be based on real-world experience, like “My friend’s startup did that and it didn’t work”. Or it can be bringing up an aspect that wasn’t considered, like privacy. As long as such new perspectives are being added to the discussion, it’s fine to continue. But when the same points are being rehashed, or someone insists strongly without being able to articulate why, the discussion has degenerated into an argument, and it’s no longer a good use of time.
⦿ Decisions have multiple factors, and the weightage given to each of them is always going to be subjective. For example, say you’re choosing between Vue and React, and it’s easier to hire React engineers, but Vue is more lightweight. If a decision is made to use Vue, and someone disagrees by saying that the ease of hiring should sway the decision to React, it’s not worth arguing about it.
⦿ Once a decision is made, give people a chance to dissent, either in person or on Slack, but they should disagree and commit to wholeheartedly executing the decision made.
Behaviors You Shouldn’t Tolerate
As a manager, if you see the following behaviors, you should clamp down on them:
⦿ People who are rude with others. We can and should be blunt regarding the product. I would welcome it if someone says “Our app sucks” if they really think it does, so that we can identify and fix the problems. This attitude shouldn’t extend to people.
⦿ People who make others feel inadequate.
⦿ People who are not there for others, for the team. We should all be confident that the team stands behind us.
⦿ People who say, “That’s not my job”. All of us should be willing to do whatever is needed, because there’s no one to do it.
⦿ People who criticise others without backing it by concrete instances. If someone says, “Santosh is a careless engineer” and follows it up by saying, “His last four commits all had a bug” that’s valuable feedback for Santosh and for the manager. But without the follow-up, it’s a baseless criticism of another person, which we shouldn’t have.
⦿ People who talk ill of others behind their back. If someone has a problem with someone else, it’s fine to check with a third party to see if he also has a problem with that person, or if it’s a misunderstanding. And if it’s a problem, to bring it up with the person the problem is with, or the manager. Such conversations, had with the intent of improving things, are always fine. But just bitching about someone is not healthy.
⦿ People who treat others with distrust, till they prove themselves. Instead, we should treat others with trust, and switch to distrust only when proven wrong repeatedly.
⦿ People who aren’t transparent, have a hidden agenda, claim to know things they don’t, make commitments without being serious about keeping them…
⦿ People who slack off when their manager isn’t looking at them.
⦿ You should lead by example, exhibiting the behaviors you want others to exhibit, and not exhibiting those you don’t.
Engineering management is a completely different game than engineering. If you understand and accept its tradeoffs, it has the potential to be impactful and satisfying, both to you and to the people you manage.