It has been about 1.5 years since I officially join the workforce, and I am currently in my 2nd full time job. Just like everything else in life, there’s ups and downs, but overall I would say that it has been very interesting, and I am still learning a lot from everyone and everything. I just want to share a little bit of my experiences and feeling to help Project Managers and Product Managers (I am mixing the 2 because all of my prior experiences mix them together as well 😑) to get their job done more efficiently and more effectively, because for me, this is one of the biggest problem I have been facing.

Have a firm grasp of the product

Just when you thought this should be very obvious, this is not always true. And as a non-product person, I absolutely hate it when PM have no idea a feature exists 😑. And for more information, please ask some of the more experience product people on how it should be done. I am just nobody.

PLAN PLAN PLAN

After you have a good grasp of the product, now you need to put everything to a timeline. One of the thing that often happens here is that the 1 person who does the planning never ask anyone anything, or worst, ask the wrong person for things that they don’t know just because he/she’s their favourite person to talk to. It is LITERALLY your job to make sure everything is on track, please spend the time to talk to the right person to understand what’s going on. You can’t predict the future and make the perfect plan, but that is not an excuse to half-ass it. The “Oh shit we missed a big piece of puzzle because we were too lazy to talk to the right person and now our timeline is screwed” situation happens way too often to me, and when you realised that, you will regret not talking to the right person earlier.

Don’t forget to manage yourself

One of the most common issue somehow is the fact than managers forgot/did not manage themselves, and I am not just talking about making sure at least 1 PM is in the office when you are in vacation. I don’t know who say it first, but one simple test it to imagine “What would happen if you are dead”, and a more realistic version of this test is “What would happen if you are too busy dealing with investors or something”. Since you are the one that shapes the product and/or make sure the right person know the right task that he/she needs to do to make that product a reality, If you are not available to answer questions, there is a pretty decent chance that either A) the world grinds to a halt, or B) we end up doing the wrong thing. Understand what you can and what you cannot do, and plan early on. It could be documentation, or just keep someone in the loop so that he/she can be more or less a perfect drop-in replacement of you. After all, it’s kinda the nature of your job to be able to delegate tasks to someone/something that can do it better/faster/both, and that include your own tasks as well.

You hire people instead of robot (I assume), use them accordingly

Unless you only hire people who is dead inside, you probably want to see that in some cases their expertises in some area beings more than just their code/design/whatever you hire them to do to the table. You probably want your employers to have mind of their own, enthusiastic, and act as an extra layer of sanity check. And as a developer, I can tell you that it absolutely salts my apple when ideas are being shot down by “because I said so” or “just believe in my craziness”. I can understand that “I need to get this other thing done first” or “I am in my zone right now”, but those ideas cannot and should not be contain. Once in awhile give those people the opportunity to voice their ideas and let them bounce around. They are LITERALLY doing your job for you, and it also means that they are actually invested in the product. I found that bouncing ideas often result in a more inclusive product, but it definitely depends on what exactly you are building. You don’t have to accept their ideas at all, this is your product and it’s not a fucking committee, but you need to be able to have more appropriate reasons when shooting them down. Basically the key is to keep their spirit up and absorb all the good bits, and to do that you need to let us out of the cage and talk once in a while.

Ideas that you can’t describe properly is just a dream

Again, another quote that I read years ago and I have absolutely no recollection on where I heard that from. Unless you are a 1 man band, you probably need to interact with people, especially people that makes what’s in your head a reality. And since we don’t have mind reading technology (yet), your ability to express those ideas and requirements are crucial, as it is the first step to making your ideas into reality. When it comes to assembly time, the idea more or less becomes nothing but the icing on the cake. From what I can tell, people judge everything by it’s cover (it’s call first impression), and if you failed to make the cover look good, you can’t get people to read the world changing content. And and it terms of execution, I don’t have much experience about that, but I would imagine that the solution to this can be combine with “Always keeps someone in the loop” that I mentioned above. In order to keep that person in the loop, keep bouncing idea from each other as sanity check, make sure your words are clear and well thought out, and keep a bible of it with ALL the reasoning and alternatives. (I am not gonna discuss documentations here because A) everyone knows how crucial it is, and B) how it should be achieve heavily depends on the context)

Don’t be afraid to discuss meta work

I think my original idea of “Avoid meta work at all cost” comes from a CGP Gray video, probably something about his productivity, and I mostly try to follow this rule, because it is battle proof (although only with a known sample size of 1). But over time I realised that I took it out of context and this does not really work in an office environment, because by the time you realised that it is too big of a problem, it’s also probably also too late. I think it works for CPG Gray is that he probably spend most of the work time along with little interaction with other people, which is not how the software engineering world works. Sometimes the developers gets fed up with everything and decided to quit; sometimes you just realised that all those days/weeks/months/years could be a lot more productive if you guys could just spend a little bit of the time to fix those bottlenecks. But again, don’t take it to extreme. Just like everything else in life, making it extreme is definitely not going to work out for you, as no one know what’s the current bug report channel/task management platform/etc. Basically what I am saying is “avoid meta work at all cost” only apply to 1 person at a time, probably.

Change/Pivot is not the key to solving problem

Obviously a lot of startup found issues that force them to pivot to survive, or because of some foreseeable issues the timeline of the project needs to be drastically alter. But you also need to remember that pivot/changing product requirement is not a magical one-size-fits-all solution. One of the most common thing that happens to me is “Oh we are running out of time so we are going to take this feature out, because after taking it out everything fits perfectly in the timeline”. The problem with it is that those features (probably) got added to the original requirement for a reason, and what you should have done instead is to proof that the original estimation is now unrealistic and what it brings to the table just isn’t worth the sacrifice, or there is nothing else that can be altered.

These are some of the tips that I can think of right now, and now I need to grab lunch. And if you have any comments, leave them below, and I will see you next time!