About 2 years ago, I took my first tentative steps into managing people and tasks. Until then, I had only ever focused on doing what I needed to do and to do it well. From my perspective, having direct responsibility over execution was always easier. Be good at what you need to do, do the tasks assigned to you within the allotted time, and you don't need to worry about much else. At least, this is the way it works when you have a good manager, every one of us should be so lucky. Having indirect responsibility, is a very different ball game. You're not directly responsible for execution but are now reliant on others to get stuff done. You are responsible for prioritizing what needs doing, and unblocking people to make sure stuff gets done on time. There were a lot of lessons learnt, some to apply to my work process, some which I have applied even to my daily life. Here are some of the most significant ones that change the way I do everything.

Make it tangible: Fail to plan and you plan to fail

If I actually want to get something done now, I always have a tangible action plan on how to achieve it. Breaking a goal down into tangible steps achieves a couple of things

1. Marking milestones: Working on something long, uncertain and intangible is a daunting process. I get anxious when something feels too nebulous and insurmountable. It starts to create a feeling of helplessness about the process. It's easier to wrap my head around something once I've broken it down into smaller steps. It also makes me feel like I've accomplished something every time I complete a step in the process. The dopamine hit of completing a step also provides me with motivation to move on to the next step of the process.
2. Spotting assumptions: Breaking a task down into tangible steps also makes assumptions obvious. When a step doesn't lead to the next, it's clearer when you write everything down. This will not always guarantee you've thought of everything, and plans can still fail, but it does prevent mistakes from poor planning. Spotting assumptions also makes it clear if you need help with any of the steps. In project-speak, you want to consult the relevant stakeholders and domain knowledge experts. If getting something out there requires marketing effort, you want to make sure to consult marketing while planning. If a feature affects the way another team does something, you want to let them know in advance so that you don't later find out it's impossible. You do not know everything. This helps you figure out what those things are.

Get straight to the point

The biggest difference between being a developer and being a Product Manager is that as a PM your time is not your own. Most of your workday is filled with meetings - getting updates, giving updates, solving problems, letting people know about problems, finding out about new problems about existing things and then if you've got time going to look for problems you don't even know about. The best thing you can do for yourself and for everyone involved is to make meetings quick and productive. Value your time, and value others' time as well.

Here are some time wasters in meetings:

1. Not sticking to the agenda: The quickest way to drag a meeting on longer than is necessary is to lose focus of the point. If there is a a side issue that is worth discussing that is taking too long, schedule a separate meeting to solve it. Invite the relevant people, and address it later. When people lose track of the point you get long meetings where nothing gets resolved.
2. Meetings to inform: Sometimes they are unavoidable, but most meetings that are project updates could have been emails. Unless action is required or something needs to be discussed, send out an email.
3. Inviting irrelevant people: Did everyone who was in the meeting need to be there? Lack of focus doesn't stop at what you talk about - it extends to who you talk about it with. What I've found helpful when thinking about who to involve is the RACI Matrix. RACI stands for:
   • Responsible: The people who actually does the work. Every task needs to have one person responsible for doing the work.
   • Accountable: The people who ensure the work gets done properly. Accountable people may not be doing the work themselves, but they are the people who need to be aware and sign off on anything related to the work.
   • Consulted: People who are not directly involved in making sure the work gets done but are either knowledgeable about the topic, or will be impacted by the work. These people will let you know if you've forgot to account for something.
   • Informed: These people need to be kept in the loop, but they don't need to be aware of every detail of the project.

Remember nothing

I don't mean this in the literal sense of course. I mean, don't rely on memory. While managing projects, sometimes I had 7 or 8 separate things to keep track of within a day. I like to think of myself as someone with a good memory, but by the end of most days I couldn't remember what I had done, let alone what I'm supposed to do tomorrow. What worked for me was to assume I would forget everything unless I wrote it down.

Everything goes on the calendar: This may sound dreadful for those who abhor structure and rigidity, but I am useless without a calendar. Every meeting, coffee chat, dinner appointment, board game night, walk in the park - everything goes on my calendar. I use it not only to remember things I have to do months from now, but also to plan my days, weeks and months. While wall-to-wall events may look daunting at first, I use my calendar as more of an aspirational guide rather than a strict regime. It allows me to plan my day, block out time and focus on what's important. Without it, I often find myself overbooked or lacking in purpose for the day. It's also helps when breaking down a project into smaller chunks. If I have an estimate of how long each part of the project will take, and I schedule that in my calendar, it gives me an idea of whether the timeline is possible.

Effective tasks: At the end of a meeting, or any discussion, if there was something to do, it would become a task. But there are some things to keep in mind when creating tasks that work:

1. Always assign someone to the task. I've lost count of the number of times when we thought that a team member would do the work and everyone thought someone else would do it, resulting in it never getting done. When creating a task, always assign it to someone, even if they're not the right person. Someone needs to be responsible for getting it done.
2. Be clear on what needs to be done. The more vague the task is, the less likely it will be that you will get what you're looking for. The more specific you are about what you need, the easier it will be for everyone to understand what needs to be done.
3. Always have a due date, even for less important things. It doesn't matter if you need to push something back, you will at least know when to check back on the task. Rather than badgering someone every hour or every day about whether the thing you need is done or not, ask them to say when they can get it done by. Then, leave them alone till the day of, or the day before if the deadline is urgent.

Project Documentation: This may sound obvious, but you'd be surprised how often good documentation is lacking on projects. You might think it's a waste of time to document everything, and on super small teams working on one thing you may not see the benefit. When you're working with 6 teams and you have to explain everything to everyone and many people are having discussions about different but overlapping parts of a project, a single document that is the source of truth for the project is essential. Forgot some details about how something works? Go back to the document. Onboarding someone new to work on it? Ask them to go through the documentation. Deprioritizing the project till next year? Good luck remembering where you were without the proper documentation.

Documentation should have information about context - why a project is being done, as well as measurable outcomes from the project. Documentation should also track what is being done, by whom and by when, and what the status of those tasks are. The benchmark of a good project document is when someone who knows nothing about the project can read the document and be ready to work on it.