My approach as an Individual Contributor to Large Initiatives @Fyle
Brief on how we run initiatives @Fyle
Feature requirements and research
The product team at Fyle engages in ongoing product research, testing various products and gathering feedback from both current and potential customers.
When they identify a potential solution that could benefit the company by attracting new customers or improving the experience of existing ones, they initiate an internal project.
The product team after doing research form a doc which usually covers the following things
Background of the problem
The data and insights gathered by the team demonstrate the existence of the problem and illustrate the potential benefits that would result from implementing the proposed feature.
Possible solution approaches based on the pattern observed in the data.
We @fyle create a separate Slack channel for each initiative.
This doc is then handed over to the Design team
Product Design
The design team, using the product document provided by the product managers, begins the design process.
During this phase, the engineering manager is consulted to ensure that the designs are feasible for implementation by the engineering team
Once the design is finalized, it is shared with the engineering team usually in the form of Figma files.
Engineering team
Following the design handoff, the engineering team takes charge of the initiative with one frontend engineer, one backend engineer, and an engineering manager typically involved.
The engineer's responsibilities include implementing the feature, testing it, deploying it to customers, and resolving any issues or bugs that arise post-deployment.
This blog will act as a guide to all the Individual contributors in engineering for ensuring the initiative's success.
Engineering Research
As an individual contributor, you frequently face challenges that require you to work on initiatives in unfamiliar areas. In such situations, conducting thorough research becomes crucial to success.
Your research process for a new area of the product typically involves three main steps.
Interact with the product end-to-end, gaining a thorough understanding of its features and capabilities
Read all available documentation related to the area.
Examine the code, including the implementation and testing, to gain a deeper understanding.
My objectives here:
By the end of the research, I try to acquire enough knowledge and understanding to be able to confidently answer any questions related to that area, whether they come from a user or an engineer.
Best practices:
During the research phase, it is advisable to create a Slack thread or document to share your findings with experts in the relevant area. This allows you to verify your understanding and receive feedback on anything you may have missed.
In this phase try to find a bug and fix it to gain more confidence in the area.
Design review
Since you may be encountering new designs for the first time, it is important to take the opportunity to ask questions and conduct a thorough engineering feasibility check.
While it may be tempting to rush through this stage due to excitement over the initiative, taking the necessary time to review the designs and address any concerns will ultimately save you a lot of time.
My objectives here:
By the end of the review, I should have a list of GET and POST calls required.
Have a list of engineering challenges that I think I might face.
By the end of the review, I should have a complete understanding of the reasons behind the specific design decisions that were made.
Best practices:
Approach the design from a user's perspective while employing an engineer's mindset. Consider each click as a potential API that you will need to build.
Create a thread to compile all of your design-related questions, and try to get answers to all the questions asynchronously If necessary, schedule a call.
Kickoff call
This call serves as a means to ensure that all parties involved in the initiative are in agreement and to address any concerns pertaining to the initiative
Typically, the individuals who participate in this call include the Product Manager, Designer, Engineering Manager, Front-end and Back-end Engineers, and Area Experts.
My objectives here:
Obtain a precise understanding of the initiative's scope.
Receive responses to any questions I may have, which were not addressed during the review or research process.
Address any concerns or blockers that I have identified.
Best practices:
Compile a list of topics for discussion in advance, so that all attendees can prepare accordingly.
Take detailed notes during the call and share them afterwards, ensuring that everyone is on the same page.
Engineering design doc
At Fyle, we place a significant emphasis on the engineering design phase as it plays a crucial role in our development process.
To streamline this process, we have established an internal engineering document template that serves as a framework for our documentation
The document includes various essential components such as
Objective Key Results: It refer to the specific goals and associated metrics that will determine the success of the initiative. These data points serve as tangible proof of the initiative's success.
Releases: initiative is broken down into multiple phases that are released over time. This approach helps to facilitate testing and enables any potential issues to be caught before the full release.
Functional Requirements: this encompasses the specific capabilities and features that the initiative will offer to each role involved
All the new APIs which we will need to build, with the contract.
All the new DB tables, columns, DB functions or indexes which you might need to create.
Any new async event which will be raised
Test cases
This doc is usually reviewed by a Senior engineer and by the Area expert.
My objective here:
The whole objective of the process is to minimize the number of surprises we may get in the implementation phase.
In instances where there are multiple solutions to a particular problem, it is important to gain agreement on the preferred approach. If necessary, senior individuals should be brought in to help facilitate this decision-making process.
Best practices:
Always try to get the document reviewed section-wise so that you can iterate faster, it will also make the reviewer's life easy and will help get unblocked faster.
Task breakdown
Breaking down large tasks into smaller, more manageable tasks is essential for efficient task completion.
At @fyle, we use ClickUp for task management. Typically, each release that we plan in the engineering design phase becomes a Milestone.
Each milestone is then further divided into smaller tasks, including tasks for OpenAPI specification, code implementation, review, testing, and deployment.
We also estimate the time required for each task in hours and assign a due date. After adding some buffer time, the due date is rolled up to the milestone
Here is an example of a task breakdown
In the example provided, the milestone is the creation of the
GET admin/reportAPI. To achieve this milestone, we have created several tasks that encompass all the necessary steps involved in creating the API.
Each task in ClickUp has an estimated time to complete and a due date based on the individual's bandwidth. After accounting for any buffer time, a final date is assigned to the milestone based on the completion dates of the individual tasks.
My objective here:
To better understand my actual bandwidth and allocate my time efficiently.
To catch any potential surprises or issues that might have been overlooked in the engineering design phase.
To give clear due dates to all stakeholders involved, helping them prepare for deliverables and manage their time.
Making a commitment to something helps me stay motivated, especially during large initiatives where it can be easy to lose focus and drive.
Unblocking frontend developers
This section pertains specifically to backend engineers. If you are not a backend engineer, feel free to skip this part
At @fyle, we prioritize concurrent development of the front end and back end.
To achieve this, we deliver the Contract for the APIs to be built after completing the Engineering design and task breakdown
With the Contract and dummy data in hand, frontend engineers can commence feature building in parallel with backend engineers.
Here is an example of an Open API spec, the same format is used for delivering contracts to the frontend team.
Best practices:
Once the Contract has been delivered, it is important to schedule a call with the frontend developer to ensure their understanding of the API and to clarify any doubts or confusion they may have.
Fast PR Reviews: Key to Unblocking Progress
When handling a significant initiative, the reviewer may face an overwhelming number of pull requests for review. As a result, it is your responsibility to ease their workload and make the review process smoother.
Best practices:
It's recommended to keep the size of pull requests under 400 lines.
Dividing implementation and tests into two separate PRs is always a good approach.
It is important to provide a clear and comprehensive description for every pull request. If the description is insufficient, consider scheduling a synchronous call to further explain the changes made in the pull request.
Maintaining Transparency
When there are many individuals involved in an initiative, it is extremely important to maintain transparency about the progress of the project and any potential delays. This allows those who depend on your work to plan and adjust accordingly.
This section will focus on the strategies that have proven effective in maintaining transparency while working on an initiative.
Regular Updates
Providing regular updates, at a frequency appropriate to the initiative, is an effective way to keep all stakeholders informed. An example update is provided below.
I prefer to include three key points in my regular updates, as depicted in the attached image: a summary of what has been accomplished, a description of what tasks are upcoming, and any delays or obstacles encountered.
Updating Tasks regularly(In our case ClickUp tasks)
Additionally, I ensure that any changes to task due dates are promptly updated in the product management tool.
I make it a point to check all tasks at least three times a week. This is especially important for teams such as customer success, who rely heavily on accurate due dates.
Keeping all the conversations on the public channel
To maintain transparency and encourage open communication, I ensure that all discussions related to the initiative are held in a public channel.
This approach not only promotes transparency, but it has also proven effective in helping me resolve issues and obtain assistance more quickly. Additionally, since the discussion takes place in a public channel, it provides greater visibility to all team members involved in the initiative.
Regular updates are important, but they do not necessarily indicate progress.
The notion that updates are equivalent to progress is a common misconception that should be dispelled. (Updates ≠ Progress)
Regardless of progress, updates should be provided regularly. Even if it's just to say that there won't be any progress due to personal leave, it's perfectly acceptable to communicate this in an update.
Ask for help efficiently
When working on a large project, it's common to encounter obstacles and dependencies on others. However, your ability to resolve those issues quickly can greatly impact the success of the initiative.
Best practices:
Be clear and specific about what you need help with. Don't beat around the bush or assume the other person knows what you're talking about.
Ask the right person, Tagging everyone is equivalent of tagging no one
Strengthen your follow-up approach, I follow up every 4-5 hours. However, if I am still blocked after multiple follow-ups, involving my manager becomes necessary. This is because it then becomes their responsibility to ensure that I am unblocked by any means.
Post-Launch Priorities and Best Practices
The post-launch phase is critical, and it's important to be on standby during this phase as unforeseen events can occur despite taking all precautions.
Best practices:
It is advisable not to undertake any major initiative immediately after launch. Instead, keep yourself available to address any high-priority issues that may arise post-launch.
It is recommended to refrain from taking pre-planned leaves during this phase.
This time can be used for tasks such as code cleanup, improving code coverage, or handling infrastructure-related tasks etc.
Reflection meeting
@fyle, we hold a reflection meeting after launch, which involves the Product Manager, Designer, Engineering Manager, and Front-end and Back-end Engineers who were part of the initiative.
The purpose of this meeting is to reflect on the initiative and analyze what worked well and what could have been improved.
My objective here:
Obtaining feedback is always beneficial. My aim is to gather actionable feedback from all stakeholders so that I can address their concerns while working on my next initiative.