What I Learnt About Project Management

• In any project, you should be clear about the non-goals — what you’re not doing as part of this project. Otherwise you’ll have scope creep.
• A plan may be wrong, but planning is still important, since it makes you think.
• A good plan today is better than a perfect plan tomorrow. Don’t worry that you don’t have all the information needed at the time of making a decision. We rarely do. Instead make the best decision you can with the information available, go ahead with the project, and re-evaluate later.
• Identify risks as early as possible, communicate them, and try to mitigate them, say by listing out risks and doing an exploratory project to bring clarity to each.
• Have a deadline, since it makes you think about how to spend time more efficiently.
• Work in an agile manner, constantly re-adjusting scope based on time, rather than making an elaborate plan up front.
• Don’t pack the schedule tightly. That makes the whole thing fragile — when one thing goes wrong, as it invariably will, the whole thing will break, like a bunch of dominoes falling. Instead, keep things flexible and decoupled. Add buffers at multiple levels. For example, assume each person is available for 37 hours (40 hours minus overhead like coordination). Don’t assume they’re available for the entire 40 hours, and don’t assume they’re available for more than 40. That’s one level of buffers. Then, if a feature needs to launch with a hard deadline of a month, and it takes a month if one person is working alone on it, add a second person if possible to make it go faster. Have buffers at multiple stages, and keep things flexible.
• When working with a new platform or in a new domain like audio processing, first figure out the basics. Get something working end-to-end, which is called a spike or a tracer bullet.
• Instead of stopping a project with two features half-done, it’s better to complete one and not even start the other.
• Your job as a project manager is to give stakeholders an estimate at the beginning of the project and, as the project progresses, to periodically keep people informed about the progress and your assessment. It’s not to tell people what they want to hear.
• Project management should be a role performed by the eng or product manager, not a separate person.
• At the end of a project, do a post-mortem where everyone contributes their ideas of what worked well and what didn’t. Don’t blame anyone during a post-mortem. The point of a post-mortem is to learn, not to point fingers.

Communication / Coordination

• A project manager spends a lot of time communicating, writing Google docs, updating Trello, etc. It’s your primary responsibility as a PM to keep things and people updated. If you re-assigned a task to another person but didn’t update it in Trello (or whatever tool you use), it means you’re not organised properly.
• Put everything in writing, whether milestones, availability of people, progress updates or anything else. It lets you organise your thoughts and communicate clearly, without confusing the recipient by rambling. A project manager told me that if there was a mis-communication, and you didn’t put it in writing, it’s your fault as a project manager.
• Everyone should own their tasks, and take responsibility. It’s not just doing it somehow, archiving the task and moving on.
• Everyone should take responsibility for coordination, such as filing a Trello card for a task that was mentioned orally or in Slack. People shouldn’t say they forgot to do something — that creates extra work for someone else to follow up. People should take responisibility, such as assigning a Trello card to someone else when they’re done with their part. Or archiving a card when it’s done. Or giving a daily update on Slack. Coordination is everyone’s job, not just the (project) manager’s job.
• Things shouldn’t fall through the cracks between functions. For example, if there’s a UX problem in the app, you should expect both the UX designer and the engineer to take interest in it. And if they haven’t, you should ask both sides why they haven’t. Don’t accept “That’s not my job” from either side.
• When you have people from different functions trying to coordinate, like eng and UX, eng can think only about speed of launch and not user value, and UX, only about quality and not timelines. I’ve been in discussions that degenerated into arguments where people weren’t listening to the other side. If you see this, stop and insist that everyone should seek to understand others before being understood themselves. Ask the engineer, “Imagine you’re not working here. You’re a user. Would you use it with this UX?” Ask the designer, “Are you suggesting delaying the launch by 1 month?” or “Today you’re asking for something, and yesterday you asked for something else. The eng team doesn’t have time for both. Which would you pick?” Ask people to prioritise and make tradeoffs, rather than insisting on an ideal world. Have people work at the intersection of eng, product, UX, etc, rather than staying comfortably in their area.
• Oral discussions are for brainstorming, but once a decision is made, it should be communicated in writing.
• Everyone should give a daily update. On Slack, not in a stand-up meeting, since the former lets each person write and read it at their convenience, rather than interrupting their work to attend a meeting, or not even starting it because they have to stop soon, anyway.

Trello (or whatever task tracking tool we use) should reflect the status of the work:

• Tasks in Trello should have all the necessary information, so that there’s no confusion or disagreement later on: “You were supposed to do X” “I was under the impression I was supposed to do Y.” Ideally, you should be able to hand off a task to anyone and they should know what is to be done without having to ask again.
• Each task in Trello should be assigned to the person doing the work.
• If one person is handing off a task to someone else, it should be done via Trello.
• If a due date has been agreed to, it should be captured in Trello.
• Any discussion on a task should be as comments on the Trello task, not out of context in Slack, to the extent possible.
• Once a task is done, it should be archived. That way, Trello tells you at a glance what work remains.
• All tasks for the current cycle (or sprint) should be in Trello so that there’s no confusion what tasks are included.

Prioritisation

• Project management is a tradeoff between time, scope, quality and cost. Scope is how many features you’ll have. Quality is UX quality and how buggy it is. Time can be calendar time (“Do it as soon as possible”) or person-hours (“This task is worth spending a person-day on”). You can’t have all. A stakeholder who’s uncompromising on all aspects is clueless — you need to push back. Figure out what’s fixed and what we can compromise on (which is different for different projects) and optimise for that. You can’t optimise without knowing the goal, and you can’t optimise for all goals at once.
• Some tasks require a lot of time and may not pay off at the end. Err on the side of saying no to these tasks, because they have a poor ROI. If you were to tell stakeholders that you spent two months on something and yielded no result, you’re a bad project manager. Instead flag these risks ahead of time so that an informed decision can be made.
• Identify what’s must-have and what’s nice-to-have, and de-prioritise the latter. Identifying and saying no to the latter creates space to do the former. You don’t want to be in a situation where you implemented a nice-to-have and didn’t have time for a must-have.
• Try to eliminate as many tasks as possible. That yields a greater benefit than trying to plan the order in which tasks should be done, because if you have four tasks that each take a person-day, it will take four person-days no matter how you slice and dice them.
• Given a choice between a task that takes a day and one that takes a week, the latter makes sense only if it has 5x user value. Don’t say yes to the latter without consciously thinking about user value. Err on the side of the one-day task. If it turns out to not be useful, you’ll have wasted a day rather than a week. Or if it turns out to take double the time, you’ll have spent two days rather than two weeks.
• Prioritise tasks by putting them in the order they should be done. Don’t assign arbitrary labels like low/medium/high or P0/P1/P2. They don’t work. They cause disagreements about whether something is a P1 or P2, which is a subjective and not a meaningful discussion to have. It also leaves open the question of which of these four P1 tasks one should do next. Ultimately the reason we prioritise is to decide which order you’ll do tasks in, so use a tool like Trello that lets you drag and drop tasks into the correct order.
• Don’t automatically fix all bugs. Prioritise which ones are important.
• A little often goes a long way. An onerous QA process that takes an hour may be overkill, but having no QA process at all may result in too many bugs being shipped. A 5- or 10-minute QA process might be ideal at an early stage, generating 80% of the value of the exhaustive QA process for 20% the cost.
• Nobody should never be idle. If no tasks are planned, do something, based on your assessment of what we need to do next. If you don’t have an assessment, pick something, anything to do. That’s still better than watching Youtube videos.
• If someone needs something from us, we should prioritise that above our own work, so that the other person can continue his work ASAP.
• Look for shortcuts that give you 80% of the benefit in 20% the cost. Make such counter-proposals: “I can do what you asked, which will take a month, or how about this other thing that doesn’t exactly do what you asked, but close, in a week?” Often, things don’t need to be done precisely in the way mentioned.

Process

• A team needs a process in place to run effectively. Process doesn’t sound like fun, but lack of process leads to chaos.
• Add process only when needed, after not having it has caused a problem, not ahead of time. Process should not be like an airport security check that’s done for the 100th passenger even if the first 99 didn’t have any prohibited items.
• Once in a while, neglect doing something that you consider important, and if nothing goes wrong, you can remove that from the process your team uses, speeding things up. For example, we had pre-commit code reviews, which we skipped doing, and nothing went wrong, so we have a more efficient process now.
• Decouple people. Minimise the number of times a person has to wait for another, because that hurts productivity. Your job is to free each person to go as fast as he can. For example, if a frontend engineer needs a backend API implemented, and the backend engineer is busy, and the frontend engineer suggests going into the backend and implementing the API himself, don’t object. A team shouldn’t be like a group of laborers carrying a heavy object, where everyone has to slow down to match the slowest person.
• In addition to decoupling people, decouple tasks. Try to figure out ways to eliminate dependencies between tasks. If one task depends on another, try to reduce scope by extracting out the independent part into a third task that can be done in parallel.
• Try to make project management asynchronous. For example, code reviews can be done after merge, to not block progress. Daily updates can be given on Slack at each person’s convenience rather than everyone having to stop work at 11 to attend a standup meeting. Making project management asynchronous reduces its overhead. Your job as a project manager is to get out of people’s way as much as possible so that they can go fast, rather than putting yourself in the middle of the road with a stop sign. The latter dis-empowers people, makes them lose their passion for the work, and get into a “why bother?” mindset, which are terrible.
• Default to permissive. Say yes by default, and say no only when there’s an actual problem it has caused. All of us believe some things, but we don’t know if they’re true unless we try the alternative.
• Don’t delay releases for features. If someone asks to hold off launching for just a day or two for them to get their feature in, it can become half a week, which can then become a week. Instead, let the release go ahead and the feature can be launched in the next release. Since anyone should be empowered to launch any time, making another release should not be a big deal. Think of it as a bus stop where the buses arrive regularly. If we’re late, the bus doesn’t wait for us. Instead, we take the next bus.
• Some changes are needed when working with a remote person. Tasks should be assigned using a tool like Trello, not orally. Bigger chunks of work need to be assigned so that people can work independently. And so on. Some of these changes are good independent of remote.
• Everybody should have a backlog of things to do. If they have to ask you, “What do I do next?” it means you didn’t do a good job. They may be working early in the morning (I sometimes start my work at 7 AM), late at night, over the weekend, or when you’re on vacation or sick. Even if you’re working at the same time, it may take you time to finish your work and respond to them, and they shouldn’t be blocked.
• Everybody should have an idea of the priority of items in their backlog. If they have to ask you, “I have tons of things in my backlog, but which is important?” it means you didn’t do a good job.

Launches

• The bar for a launch is whether anything is worse than the already launched version. If problems have been found, but they’re already in the launched version of the product, they should not hold up the launch. Launches shouldn’t get delayed for reasons unrelated to the feature being launched. Unless they’re critical like crashing for many users, leaking private data, etc.
• We often worry that people won’t like something. Instead, Just Do It. If people complain, we can always fix it later. We’re not Google with a billion users. We should move fast and break things. If we’re worried about breaking things, it means we’re overly cautious.
• Any engineer can release whenever he wants. You should have a documented launch process that anyone can follow and launch. Coming up with procedures and documenting them lets people move fast without having to wait for everyone to be available before launching. Procedures need not be onerous. It can just be a 5-step list in a Google doc. Why does it matter for anyone to be able to launch any time? First, when an engineer is done building a feature, users benefit by getting the improvement early. If we have a weekly release cycle, it can take up to a week for the feature to go live, and in that time, users don’t benefit from the feature. Second, with a weekly release cycle, the engineer will have to work on something else till it launches. Multi-tasking is a huge productivity loss, to the extent that it’s a myth. Third, if three iterations turn out to be needed, a weekly release schedule means that it will take three weeks. But when people are empowered to launch whenever they want, they might complete the whole process in a day. Fourth, nothing makes an engineer more happy than quick iterations and seeing the results of his work go live ASAP. That will help him get in the zone, letting him do more. People are not machines that produce output at a constant rate. When they’re in the zone, they get a lot done, and (project) managers need to get out of the way. On the other hand, if people are made to run through knee-deep water, they lose their morale. They’ll then stop bothering, and that’s toxic. Project management is about people as much as it is about projects.

Project management isn’t sexy, but it’s valuable — if not done well, it can cause the project to fail. And at a personal level, you can take pride in a project that was planned well and executed well.

Also read:

• How I Plan Milestones
• What I Learnt About Estimation
• What I Learnt About Product Management