How do we get things done at Peerlist?

Hey folks,

It's been quite a while for me to write an article, so I thought of writing something which I get asked many times, with a tiny team size, how you can get so much done?

Spoiler Alert! This article might not help you in coming up with a rock-solid process, but it will surely help you declutter the mess just the way we did step-by-step.

So, let’s begin!

We started building Peerlist a year back as a side project, so till last December, all the processes, how to work, how to plan and execute, all of these questions did not matter. We used to be very spontaneous in how we worked, planned, and executed. This is perfectly fine when you are a team of two people working with each other.

But after December, our team became a team of 4 😎

You must have laughed, as this is still a small number. But if you look at it the other way, we had scaled our team 2x (😂). So within the first week, we all realized we needed to develop some patterns to work. Not something with too heavy planning or following some strict sprints, but at least some way to make the execution less chaotic and more productive.

With this realization, we started finding a good way of working and finding the fitting process.

Finding our process

This required many attempts until we finally developed a better approach to working. But I will still walk you through them as they have excellent learnings.

Attempt 1: Document and work

We all always explain to each other the importance of documentation. So we decided to go ahead with that to get better clarity and to plan better.

The method was simple; we used to decide what feature we wanted to build, write down the detailed PRD and edge cases, plan the work, calculate time estimates, execute, test, and deploy.

This method works! Having things written down in front of you, knowing requirements properly, and understanding all the edge cases, helps a lot to plan your tasks in a better way. We initially loved the process unless we started understanding some issues in it.

1. For a team of 4 people, writing a detailed PRD was very time-consuming. Without it, there was going to have a lot of confusion and chaos; but we still had to make that trade-off. You realize this mainly after calculating the time-required vs. execution ratio.

2. With documentation, one mistake we made was using too many apps and creating more than one source of truth. We used Google Drive, Notion, Linear, and Github READMEs all at once, making a mess again! There are some things to consider here; being a small startup and team, you want to explore cost and productivity of these products along with the learning curve and ease of use for all. But we lost track of how many apps we used and what was stored where? So eventually, a mess! 😇

Attempt 2: Single source of truth, strict deadlines, and bi-weekly cycles.

From experience, we understood that we need to improve on two things, heavy documentation and multiple resources. So we narrowed our resources to using only Linear and Notion. We used Notion to write down requirements, descriptions, and Linear to divide them into tasks.

Linear has this feature of working in cycles and tracking down your completion percentage per cycle. I must say, this works as a dopamine hit! Every task you finish makes you feel so good because of the percentage of completion of tasks in that cycle increases.

The only mistake that happened with this approach was bi-weekly cycles. So instead of working on a single feature for the correct amount of time, we started to accumulate a feature somehow in the timeline of 2 weeks!

This wasn’t a good approach as the aggressive deadlines helped us finish only 60-70% of the work in a cycle, giving us a feeling of not achieving enough. Hence, negatively impacting all of us.

We all understood the need to change the pattern again!

Attempt 3: Parallel Working (A disaster!)

In our second attempt only, we were close to finding an excellent method to work. But as I always say, if everything goes well, how can we even call it a startup 😁

So, we went ahead with another method to work, parallel working! We have been working together for around 3-4 months now, and we wanted to improve our speed. Hence, we decided to work on different features individually rather than on the same feature as a team!

This wasn’t an excellent decision. This backfired us, and we ended up delivering nothing significant. Though this being said, after all these attempts, we got some fantastic lessons about working as a team. Here are some of them 👇

1. Working as a team with a single focus helps you best in productivity. In addition, it keeps your morale high because you have a team by your side; even if things go wrong, we all will be there to face it!

2. Working together adds a sense of accountability. You will always feel that someone is stuck because of you or someone has a dependency on your work, making you deliver things faster and better.

3. You all collectively think about the pros and cons of doing things in a particular way, finding solutions, etc., so you get answers faster. If you don’t know about something, there is a high chance your teammate can fix it for you!

4. Having less software and fewer things to update will improve your focus. You need to take care of one thing, and you are done. Decluttering becomes easy, and you know exactly where you will find that thing whenever you are stuck.

5. You cannot break some features in fixed timelines. Some will take a lot of time, and some will get done very quickly, and all of that is okay!

6. You have to give it the time it requires. Keeping very aggressive deadlines can create more mess and will aggressively backfire!

7. Finding the correct process is also a process. It will evolve every day.

So, after all these lessons, here is something which works best for us (at the moment). Not saying this is a perfect way to get things done, but we can ship faster with this; that is what matters, and we love it!

How are we working now?

This time, we decided to keep things extremely simple. With a slight change, we went back to work on a single feature as a team. So this is what our typical work method looks like -

1. We decide on one feature we want to build, and we divide that feature into smaller sections that can be achieved within a week.

2. Every section of a feature goes through four parts in the following sequence, design, APIs, UI, and testing.

3. Every Wednesday, we do a week’s planning where we pick sections considering their complexity and feature flow and decide on small tasks per individual.

4. We write down all the tasks in a Slack msg and pin it to the channel (Yes, on SLACK). This way, the to-do list for all of us is right in front of us. We don’t need to waste too much time switching and maintaining apps plus, whenever we miss any task, we just add it in a thread, and we are good. I can assure you that this is the simplest way to maintain a team’s task list.

5. Every Wednesday, we can review the previous list, find out what is not done, and add it to our new list.

6. We meet once a day for 10 mins just to have a small sync-up on the tasks and if anyone is dependent/blocked for anything.

7. For every new feature explanation, we started recording a small video (max 5 mins, thanks to Loom!). This helped us get the detailed PRD without wasting too much time writing it down.

8. Once done, we deploy a feature to our staging environment, test it thoroughly and then deploy it to prod.

After adopting this process, we noticed a drastic shift in productivity, execution, and delivery.

On an ending note, I would just say that every individual and every team works differently. Working in an environment where things are stable, and processes are set is fun. Working in an environment where you are evolving along with the processes is exciting.

If you are still here reading it, thank you so much for following it up till now, I genuinely appreciate it. If you are still not a user of Peerlist, you should join it! It's a proof of work alternative to your LinkedIn profile.

Also, if you have any questions about Peerlist, let me know in the comments. I would love to answer them all and finding a new topic to write an article on is, anyway, extremely difficult, so help me with that! 😉

Keep growing! 🙌