Vikas Prasad @ Fyle

Hello mate

This document is a user manual to Vikas Prasad. It documents how I operate, and the purpose of the doc is to make the collaboration between us super smooth. I am learning every day, so this is going to be a living doc. I will keep editing it based on the new practices that I start following and removing off any obsolete information with time. 🌟

Why the need for this doc?

I started as an IC at Fyle, went ahead and started mentoring interns, then mentoring and leading junior folks, then managing senior folks. Over time and with people, I have seen myself communicating (or assuming to be already known by my reports) similar pieces of information. That's where the need for this doc arisesπŸ“„. I want to document it all so that I can reuse it with any new person I start working with + I can explicitly add those points, which I always "wished" my reports understood, but I never communicated it to them.

About myself

I work as an Engineering Manager 1 with Fyle. In one line, my job is to make my reports successful.

Apart from work, I am fascinated by adventurous activities πŸ…. I also like to explore new places and live new experiences a lot, and I like to learn new stuff. I like having a couple of morning hours for myself - it could be anything like meditation, a walk, run, strength training, swimming, rock climbing lessons or any other physical activity. In my free time, I sometimes read, sometimes listen to music or read lyrics, sometimes tease my cat etc.

If there is one superpower I could have, I would want it to be able to communicate verbally with any living organism - not just humans.

If I had an infinite supply of money: a) I would be moving from place to place exploring new experiences b) I would be learning new skills all the time c) I would be helping others with whatever skills I possessed.

If I were a song, I would be

If I were a dance, I would be

I firmly believe hard work beats talent and consistency beats hard work. I am fortunate that I am working with Fyle - one of the reasons for that is that a lot of the values that Fyle as a company lives by resonates well with me.

One thing I cannot say no to is a supple invitation to a TT match.

What is my job and how do I work?

As mentioned above, the simplest definition for my job that I follow is making my reports successful (which in turn makes me successful). I also like to look at it with this analogy where I consider you an elite sportsman, and myself as the manager of that elite sportsman. Your job: to perform. My job: to help you perform your best - making sure you have all the resources in place to best play your sport πŸ….

This mindset helps me cover everything else: the delivery of initiatives, communication with other teams, roadmap plans, estimates, planning around potential dangers, finding new team members, maintaining team health etc.


I truly hate notifications (from any application - work or non-work). They are interruption-driven, unpredictable and directly attack my attention πŸ””. This means I have prepared my own guards around it. What does it mean for you?

  • Slack is the most real-time platform for me. If you have communicated with me on any other platform (email, Clickup, Github, Notion etc.), please drop a note on Slack about it, so that I read them faster. Other than Slack, everything else I read either just once a day or even lesser frequency than that - (unless you ping me on Slack to check something).
  • Slack messages get responded to in real-time. Only two scenarios, for which there could be a delay in response for a Slack message: a) I am not around b) I am around but working on something outside of Slack

In both of these cases, as soon as I am back to Slack, you will get a response.

Also, in both of such cases, if there is something for which you need to connect with me right then, PLEASE feel free to directly call on my mobile - that's the only way that would work. Even sending forced notifications on Slack when in DnD won't work :) - sorry, but while working, my guards to defend notifications are very strong. Please please please feel completely comfortable calling me on the phone if you don't see me responding on Slack and you need to connect immediately - it is absolutely fine with me, both during working and non-working hours.

  • In case I have mentioned that I would check something and get back, and if you feel it's quite a time, please feel free to follow up. Your query would definitely not go unanswered, but following up just makes me reprioritise your request. So don't think much when following up.
  • If there is something that could have been talked about in a public channel, and you send a DM about it, I would immediately ask you to move the conversation to a public channel. This not only keeps everyone updated, but I personally sort message reading by reading public messages first and then only DMs.


We would use sync ups to track progress on our initiatives. The frequency of these meets would vary from initiative to initiative and team to team. Here are the main things to have in mind for these meets:

  • We would cover what we did and what are we going to do next
  • We would have deadline commitments(posted publicly) to the next set of items that we identify
  • We would see how far we are from reaching the objective and are we on track. If in danger, replan
  • Have a check on the set of items that we are doing are actually helping us move towards our objective. If we catch any such item that's not helping us reach the objective, we would deprioritise it
  • We will drop notes from the meet, right after the meet in the relevant public channel

Friday Demos

We have this forum where people share whatever small or big things they achieved throughout the week with each other on Friday evening. I want your work to have visibility, so I would recommend sharing your weekly wins in this forum.

Because of the ambitious goals that we are setting, if we miss them and also do not acknowledge the progress that we have made thus far, it can soon become depressing. That's why the Friday sessions. This is about what small, big things we achieved. Feel free to show off any of these:

  • Snippets from upcoming features.
  • If you went through long customer interviews and extracted insights from them, share interesting points.
  • If you devised the key results for the initiatives, share them.
  • If you defined criteria for beta users and compiled the list, share them.
  • If you worked on a rough mockup, share it. If you worked on designs, share them.
  • If you got the prototype tested by customers, share how was the experience.
  • If you re-did an API show it off. If you ran performance numbers on DB, share the results.
  • If you did A/B testing, talk about it. If you ran a campaign, share the highlights.
  • If you wrote tests, share the coverage. If you hit a KR, boast it.
  • If you purchased a software, show around it.
  • If you talked to a customer, share it. If you got a radical feedback from a customer, share it. If you got a quote from customer, celebrate it.

Basically, share something. And to share something, you would seek wins during the week. One side-effect advantage of this is that people will understand what one does all day. And we would be able to view the work done towards the objective.


1x1s are your time. We would generally start with a weekly 30 to 45 mins meeting, and then based on mutual needs might dial down the frequency if needed. Based on other events, I might move the meeting to another day within the week but would finish a week's 1x1 within that week itself.

  • This is your meeting, so you bring in the agenda. I am here to listen to you. If you do not have anything to discuss, you decide whether to drop the meet.
  • You can discuss anything non-operational in these meetings. Discussions related to career growth, something bothering, clarification around some company process/policy, company culture, what's happening in other departments etc. etc.
  • Even if I do not have the answer to your query at the moment, I would take note of it, find the answer and then update you πŸ€—.
πŸ’‘ Also, just because 1x1 happens once a week, it doesn't mean if there's anything that's bothering you and eating up your mind you need to wait for the next 1x1 to come. If there is a p0 concern that you need to talk about immediately, just ping and we will talk immediately in an ad-hoc meet.
  • I will use a small section of your time in 1x1 to communicate to you any feedback that's relevant which can be worked upon by you.


When I see you pushing your limits or achieving a milestone, I will be announcing it on public channel very loudly πŸ”Š. I have also learnt that just like feedback, shoutouts also need to be fresh. So, I will most likely do it as soon as I notice a milestone. If I find something inspiring, educational or motivating from you then also I do shoutouts even if it might seem a small achievement for the outside world.

Other than the public announcement, I would also cover these in our 1x1.


I believe having a feedback mechanism is a very useful tool to observe and attack one's blindspot(s).

  • Feedback from me would be always private. Whenever I notice a scope of development, I would immediately bring it to your knowledge in our 1x1.
  • Feedback from me would be straight - without any convolution, as I myself struggle in reading between the lines when it comes to feedback. This doesn't mean my tone would be rude. You would find me communicating all the difficult feedback calmly and politely. If you sense otherwise, please report to me.
  • Feedback from me would always have at least one example instance to help you connect with it much easily.
  • Feedback from me would always have a "why" part. Why is the mentioned point important. What value does it bring? What is at cost here?
  • For each feedback, I will seek your input to understand if you are also on the same page or if I have completely misread a situation. Based on it, we will agree to attack and solve this problem together πŸ™ŒπŸΌ
  • Since feedback are such a strong cheat code to improve oneself, it means I also seek them. If and when you have a feedback for me, please feel free to bring them to me, preferably in the above-mentioned fashion 🀝
  • If as part of an initiative, you ended up working with leaders from other teams, I would make sure to collect feedback(and shoutouts) from them, so that those can be covered in our 1x1s

Decision Making / Autonomy

My eventual goal while working with you is to make you reach the state of absolute independence πŸͺ

  • This means every time you come up to me with a question, the very first response that you would get is "what do you think we should do?"
  • This means when you come up with a problem, it would benefit a lot if you bring add-ons of potential solutions from your side. These need not be "the" solution. We will reach "the" solution through a discussion. As long as you have spent time thinking about solutions and have some proposals, it works. The idea is to make your brain start moving to be in position to make decisions yourself one day, and that is why we need this practice. I have followed this methodology with many folks here at Fyle, and it works :)
  • I will help to guide you to the right solution or choose the right solution. The ask here is just one: when coming with a problem, have some solution proposals also ready with you.

Seeking help

No one person knows everything, and everyone needs help from each other from time to time πŸ«‚. Here I list the smart way of doing it:

  • When seeking help, make sure that you have done your part. Let's say you need help with debugging a bug. Have you already tried reproducing the bug? Did you trace out the code which is causing the issue? Did you use breakpoints/loggers to see the expected vs real values of variables? Did you try playing around by changing different values? Did you read the error and googled about it?
  • If you think about it, all the steps mentioned above are something you already are capable of doing. So if you are on a call seeking help, and we end up doing these steps, then it's not a "smart help". You did not learn anything new here. I did not teach anything new here.
  • So make sure that you have done your part when you are seeking help. You have tried all things that you already know. And you have the answers ready to the follow-up questions that you anticipate from helper. All of this helps in closing the problem faster with minimum frustration.
  • If at the end of a help session, you end up learning something new, that you did not already know, then it's a win for me (no matter how much time it took). On the other hand, if at the end of a help session, the problem was solved by doing something that you could have already done, then it's a big loss for me - because that time I could have potentially spent with another junior person to teach them something new.

What disappoints me?

With time, I have noticed a few patterns that really sadden me. I will list them out below so that we all can avoid going down that road:

  • When a feedback was discussed and agreed on, but I end up giving the same feedback on multiple further occasions without seeing any progress. If the feedback doesn't resonate with you, I would really appreciate you bringing it up when we are discussing it in the first place. But if an agreement is made, and even then it's repeating, it brings frustration.
  • Unprepared help-seeking sessions. This eats a lot of valuable time for both the parties.
  • Bad internet. We are working remotely now. Clear voice on calls is a must! Unclear sound simply doesn't work. Please invest in a good internet setup and get it reimbursed. If your machine has problems, then get your machine fixed - we just cannot afford poor communication because of technological issues. If you have any ideas that can improve our collaboration using technologies, bring them to me.
  • Poorly framed sentences in a message/doc. No, I am not a Grammar Nazi - but if you have written something that is just understandable to you, and for me to understand it I anyway have to get on a call with you, then why did you write it in the first place? You get the point? As long as your message is clear enough - has no cryptic sentences, it becomes very easy for me to quickly process and revert to it. If it's poorly framed, and I do not understand it in my first read, very likely of me to respond to it when I get "free" enough to re-read and understand it.

Things I am not currently good at and need to get better at

Unfortunately, I am yet to become a superhuman, which means there are plenty of things that I also need to get better at. The current set of items that I need to improve upon are:

  • Overcommitments. This includes reducing the TAT for unblocking folks dependent upon me. This is also needed to have some free time for the mind so that there is space for tinkering around and to plan for what’s possible next
  • Time and energy management
  • Handling/Managing information overload
  • Being more consistent. I am focused, dedicated, motivated, and hardworking, but I need to work on consistency. Right now it's flow driven - when I get into the flow I close stuff off, when I am out of flow, I struggle. I want it to be more controlled
  • Controlling the length of my meetings. Almost every meeting I run, always overshoots the dedicated time - this creates chaos in the whole schedule. I need to fix this.

These are the ones that I have identified. If you observe any other item that I can improve on, please bring it to my notice and help me become a superhuman πŸ‘Ή

In the end, I would like to reiterate that the purpose of this doc is to enable smooth collaboration between us. This is not a Dos and Don'ts notice. And above all, this is open to suggestions - if you feel any section of the doc isn't clear or if you feel any new specific section to be added, care to share.

I hope we both have a great experience working with each other and enable each other to reach our next level. I assure that you would receive the safety and empathy needed to work this out.

Vikas Prasad

I am a Member of Technical Staff at Fyle. When not at work, I love spending time with my cat. I am known to plug-in Hindi songs into random conversations.

More of our stories from

Interview Experience: Backend Engineering Internship at Fyle

Wanna know the secret to crack backend engineering interviews? Learn them here and intern at Fyle!

The curse of being a Senior Engineer, how to deal with timelines, frustrations, etc

Being a good developer is 50% skill and 50% emotional support; here's my secret to balancing both at the right amount!

How did I build cropping of receipts in the mobile app?

Follow Yash's journey of what it takes to reduce manual work for our customers when receipts come in all shapes and sizes!

How did we increase Data Extraction accuracy by a whopping ~50%?

Wanna know the secret of data extraction, the complex machine learning models we use, the experiments we did? Read on...

The not so secret sauce of my work

From chaos to clarity, follow Chethan's not so secret sauce to excelling at work!

From Zero to Hero: The Policy Tests Journey!

The story of policy tests at Fyle

How Fyle changed my life from a naive intern to a confident Engineering Lead

A blogpost that documents Shwetabh's journey at Fyle.

Vikas Prasad @ Fyle

This document is a user guide to Vikas at work.

Gokul K's README

This document is a user guide to Gokul at work.


All Topics