How Typo Uses DORA Metrics to Boost Efficiency?

DORA metrics are a compass for engineering teams striving to optimise their development and operations processes.

Consistently tracking these metrics can lead to significant and lasting improvements in your software delivery processes and overall business performance.

Below is a detailed guide on how Typo uses DORA to improve DevOps performance and boost efficiency:

What are DORA Metrics?

In 2015, The DORA (DevOps Research and Assessment) team was founded by Gene Kim, Jez Humble and Nicole Forsgren to evaluate and improve software development practices. The aim was to improve the understanding of how organisations can deliver software faster, more reliable and of higher quality.

They developed DORA metrics that provide insights into the performance of DevOps practices and help organisations improve their software development and delivery processes. These metrics help in finding answers to these two questions:

  • How to identify organisations’ elite performers?
  • What should low performers teams must focus on?

The Four DORA Metrics

DORA metrics helps in assessing software delivery performance based on four key (or accelerate) metrics:

  • Deployment Frequency
  • Lead Time for Changes
  • Change Failure Rate
  • Mean Time to Recover

Deployment Frequency

Deployment Frequency measures the number of times that code is deployed into production. It helps in understanding team’s throughput and quantifying how much value is delivered to customers.

When organizations achieve a high Deployment Frequency, they can enjoy rapid releases without compromising the software’s robustness. This can be a powerful driver of agility and efficiency, making it an essential component for software development teams.

One deployment per week is standard. However, it also depends on the type of product.

Why is it Important?

  • It provides insights into the overall efficiency and speed of the DevOps team’s processes.
  • It helps in identifying pitfalls and areas for improvement in the software development life cycle.
  • It helps in making data-driven decisions to optimise the process.
  • It helps in understanding the impact of changes on system performance.

Lead Time for Changes

Lead Time for Changes measures the time it takes for code changes to move from inception to deployment. The measurement of this metric offers valuable insights into the effectiveness of development processes, deployment pipelines, and release strategies.

By analysing the Lead Time for Changes, development teams can identify bottlenecks in the delivery pipeline and streamline their workflows to improve software delivery’s overall speed and efficiency. Shorter lead time states that the DevOps team is more efficient in deploying code.

Why is it Important?

  • It helps organisations gather feedback and validate assumptions quickly, leading to informed decision-making and aligning software development with customer needs.
  • It helps organizations gain agility and adaptability, allowing them to swiftly respond to market changes, embrace new technologies, and meet evolving business needs.
  • It enables experimentation, learning, and continuous improvement, empowering organizations to stay competitive in dynamic environments.
  • It demands collaborative teamwork, breaking silos, fostering shared ownership, and improving communication, coordination, and efficiency.

Change Failure Rate

Change Failure Rate gauges the percentage of changes that require hot fixes or other remediation after production. It reflects the stability and reliability of the entire software development and deployment lifecycle.

By tracking CFR, teams can identify bottlenecks, flaws, or vulnerabilities in their processes, tools, or infrastructure that can negatively impact the quality, speed, and cost of software delivery.

0% — 15% CFR is considered to be a good indicator of your code quality.

Why is it Important?

  • It enhances user experience and builds trust by reducing failures.
  • It protects your business from financial risks which helps in avoiding revenue loss, customer churn, and brand damage by reducing failures.
  • It helps in allocating resources effectively and focuses on delivering new features.
  • It ensures changes are implemented smoothly and with minimal disruption.

Mean Time to Recovery

Mean Time to Recovery measures how quickly a team can bounce back from incidents or failures. It concentrates on determining the efficiency and effectiveness of an organisation’s incident response and resolution procedures.

A lower mean time to recovery is synonymous with a resilient system capable of handling challenges effectively.

The response time should be as short as possible. 24 hours is considered to be a good rule of thumb.

Why is it Important?

  • It enhances user satisfaction by reducing downtime and resolution times.
  • It mitigates the negative impacts of downtime on business operations, including financial losses, missed opportunities, and reputational damage.
  • It helps meet service level agreements (SLAs) that are vital for upholding client trust and fulfilling contractual commitments.
  • It provides valuable insights in day to day practices such as incident management, engineering team performance and helps elevate customer satisfaction.

The Fifth Metrics: Reliability

Reliability is a fifth metric that was added by the DORA team in 2021. It measures modern operational practices and doesn’t have standard quantifiable targets for performance levels.

Reliability comprises several metrics used to assess operational performance that includes availability, latency, performance and scalability that measures user-facing behaviour, software SLAs, performance targets, and error budgets.

How Typo Uses DORA to Boost Dev Efficiency?

Typo is an effective software engineering intelligence platform that offers SDLC visibility, developer insights, and workflow automation to build better programs faster. It offers comprehensive insights into the deployment process through key DORA metrics such as change failure rate, time to build, and deployment frequency.

Below is a detailed view of how Typo uses DORA to boost dev efficiency and team performance:

DORA Metrics Dashboard

Typo’s DORA metrics dashboard has a user-friendly interface and robust features tailored for DevOps excellence. This helps in identifying bottlenecks, improves collaboration between teams, optimises delivery speed and effectively communicates team’s success.

DORA metrics dashboard pulls in data from all the sources and presents in a visualised and detailed way to engineering leaders and development team.

DORA metrics helps in many ways:

  • With pre-built integrations in the dev tool stack, DORA dashboard provides all the relevant data flowing in within minutes.
  • It helps in deep diving and correlating different metrics to identify real-time bottlenecks, sprint delays, blocked PRs, deployment efficiency and much more from a single dashboard.
  • The dashboard sets custom improvement goals for each team and tracks their success in real-time.
  • It gives real-time visibility into a team’s KPI and lets them make informed decisions.

How to Build your DORA Metrics Dashboard?

Define your objectives

Firstly, define clear and measurable objectives. Consider KPIs that align with your organisational goals. Whether it’s improving deployment speed, reducing failure rates, or enhancing overall efficiency, having a well-defined set of objectives will help guide your implementation of the dashboard.

Understanding DORA metrics

Gain a deeper understanding of DORA metrics by exploring the nuances of Deployment Frequency, Lead Time, Change Failure Rate, and MTTR. Then, connect each of these metrics with your organisation’s DevOps goals to have a comprehensive understanding of how they contribute towards improving overall performance and efficiency.

Dashboard configuration

Follow specific guidelines to properly configure your dashboard. Customise the widgets to accurately represent important metrics and personalise the layout to create a clear and intuitive visualisation of your data. This ensures that your team can easily interpret the insights provided by the dashboard and take appropriate actions.

Implementing data collection mechanisms

To ensure the accuracy and reliability of your DORA Metrics, establish strong data collection mechanisms. Configure your dashboard to collect real-time data from relevant sources, so that the metrics reflect the current state of your DevOps processes.

Integrating automation tools

Integrate automation tools to optimise the performance of your DORA Metrics Dashboard.

By utilising automation for data collection, analysis, and reporting processes, you can streamline routine tasks. This will free up your team’s time and allow them to focus on making strategic decisions and improvements.

Utilising the dashboard effectively

To get the most out of your well-configured DORA Metrics Dashboard, use the insights gained to identify bottlenecks, streamline processes, and improve overall DevOps efficiency. Analyse the dashboard data regularly to drive continuous improvement initiatives and make informed decisions that will positively impact your software development lifecycle.

Comprehensive Visualization of Key Metrics

Typo’s dashboard provides clear and intuitive visualisations of the four key DORA metrics:

Deployment Frequency

It tracks how often new code is deployed to production, highlighting the team’s productivity.

By integrating with your CI/CD tool, Typo calculates Deployment Frequency by counting the number of unique production deployments within the selected time range. The workflows and repositories that align with production can be configured by you.

Cycle Time (Lead Time for Changes)

It measures the time it takes from code being committed to it being deployed in production, indicating the efficiency of the development pipeline.

In the context of Typo it is the average time all pull requests have spent in the “Coding”, “Pickup”, “Review” and “Merge” stages of the pipeline. Typo considers all the merged Pull Requests for the main/master/production branch for the selected time range and calculates the average time spent by each Pull Request in every stage of the pipeline. No open/draft Pull Requests are considered in this calculation.

Change Failure Rate

It shows the percentage of deployments causing a failure in production, reflecting the quality and stability of releases.

There are multiple ways this metric can be configured:

  • A deployment that needs a rollback or a hotfix: For such cases, any Pull Request having a title/tag/label that represents a rollback/hotfix that is merged to production can be considered as a failure.
  • A high-priority production incident: For such cases, any ticket in your Issue Tracker having a title/tag/label that represents a high-priority production incident can be considered as a failure.
  • A deployment that failed during the production workflow: For such cases, Typo can integrate with your CI/CD tool and consider any failed deployment as a failure.

To calculate the final percentage, the total number of failures are divided by the total number of deployments (this can be picked either from the Deployment PRs or from the CI/CD tool deployments).

Mean Time to Restore (MTTR)

It measures the time taken to recover from a failure, showing the team’s ability to respond to and fix issues.

The way a team tracks production failure (CFR) defines how MTTR is calculated for that team. If a team considers a production failure as :

  • Pull Request tagging to track a deployment that needs a rollback or a hotfix: In such a case, MTTR is calculated as the time between the last deployment till such a Pull Request was merged to main/master/production.
  • Tickets tagging for high-priority production incidents: In such a case, MTTR is calculated as the average time such a ticket takes from the ‘In Progress’ state to the ‘Done’ state.
  • CI/CD integration to track deployments that failed during the production workflow: In such a case, MTTR is calculated as the average time between that deployment failure to its being successfully deployed.

Benchmarking for Context

  • Industry Standards: By providing benchmarks, Typo allows teams to compare their performance against industry standards, helping them understand where they stand.
  • Historical Performance: Teams can also compare their current performance with their historical data to track improvements or identify regressions.

Find out what it takes to build reliable high-velocity dev teams:

How Does it Help Engineering Leaders?

  • Typo provides a clear, data-driven view of software development performance. It offers insights into various aspects of development and operational processes.
  • It helps in tracking progress over time. Through continuous tracking, it monitors improvements or regressions in a team’s performance.
  • It supports DevOps practices that focus on both development speed and operational stability.
  • DORA metrics help in mitigating risk. With the help of CFR and MTTR, engineering leaders can manage and lower risk, ensuring more stability and reliability associated with software changes.
  • It identifies bottlenecks and inefficiencies and pinpoints where the team is struggling such as longer lead times or high failure rates.

How Does it Help Development Teams?

  • Typo provides a clear, real-time view of a team’s performance and lets the team make informed decisions based on empirical data rather than guesswork.
  • It encourages balance between speed and quality by providing metrics that highlight both aspects.
  • It helps in predicting future performance based on historical data. This helps in better planning and resource allocation.
  • It helps in identifying potential risks early and taking proactive measures to mitigate them.


DORA metrics deliver crucial insights into team performance. Monitoring Change Failure Rate and Mean Time to Recovery helps leaders ensure their teams are building resilient services with minimal downtime. Similarly, keeping an eye on Deployment Frequency and Lead Time for Changes assures engineering leaders that the team is maintaining a swift pace.

Together, these metrics offer a clear picture of how well the team balances speed and quality in their workflows.

How to engineer your feedback?

One of the ways organizations are implementing is through a continuous feedback process. While it may seem a straightforward process, it is not. Every developer takes feedback in different ways. Hence, it is important to engineer the feedback the right way.

Why is the feedback process important?

Below are a few ways why continuous feedback is beneficial for both developers and engineering leaders:

Keeps everyone on the same page: Feedback enables individuals to be on the same page. No matter what type of tasks they are working on. It allows them to understand their strengths and improve their blind spots. Hence, provide high-quality work.

Facilitates improvement: Feedback enables developers the areas they need to improve and the opportunities they can grab according to their strengths. With the right context and motivation, it can encourage software developers to work on their personal and professional growth.

Nurtures healthy relationships: Feedback fosters open and honest communication. It lets developers be comfortable in sharing ideas and seeking support without any judgements even when they aren’t performing well.

Enhances user satisfaction: Feedback helps developers to enhance their quality of work. This can have a direct impact on user satisfaction which further positively affects the organization.

Strength performance management: Feedback enables you to set clear expectations, track progress, and provide ongoing support and guidance to developers. This further strengthens their performance and streamlines their workflow.

How to engineer your feedback?

There are a lot of things to consider when giving effective and honest feedback. We’ve divided the process into three sections. Do check it out below:

Before the feedback session

Frame the context of the developer feedback

Plan in advance how will you start the conversation, what is worth mentioning, and what is not. For example, if it is related to pull requests, can start by discussing their past performance related to the same. Further, you can talk about how well are they performing, whether they are delivering the work on time, rating their performance and action plan, and if there are any challenges they are facing. Make sure to relate it to the bigger picture.

When framed appropriately and constructively, it helps in focusing on improvement rather than criticism. It also enables developers to take feedback the right way and help them grow and succeed.

Keep tracking continuously

Observe and note down everything related to the developers. Track their performance continuously. Jot down whatever noticed even if it is not worth mentioning during the feedback session. It allows you to share feedback more accurately and comprehensively. It also helps you to identify the trends and patterns in developer performance and lets them know that the feedback isn’t based on isolated incidents but rather the consistent observation.

For example, XYZ is a software developer at ABC organization. The engineering leader observed XYZ for three months before delivering effective feedback. She told him:

  • In 1st month, XYZ wasn’t able to work well on the initial implementation strategy. So, she provided him with resources.
  • In 2nd month, he showed signs of improvement yet he hesitated to participate in the team meetings.
  • In 3rd month, XYZ’s technical skills kept improving but he struggled to engage in meetings and share his ideas.

So, the engineering leader was able to discuss effectively his strengths and areas of improvement.

Understand the difference between feedback and criticism

Before offering feedback to software development teams, make sure you are well aware of the differences between constructive feedback and criticism. Constructive feedback encourages developers to enhance their personal and professional development. On the other hand, criticism enables developers to be defensive and hinder their progress.

Constructive feedback allows you to focus on the behavior and outcome of the developers and help them by providing actionable insights while criticism focuses on faults and mistakes without providing the right guidance.

For example,

Situation: A developer’s recent code review missed several critical issues.

Feedback: “Your recent code review missed a few critical issues, like the memory leak in the data processing module. Next time, please double-check for potential memory leaks. If you’re unsure how to spot them, let’s review some strategies together.”

Criticism: “Your code reviews are sloppy and miss too many important issues. You need to do a better job.”

Collect all important information

Review previous feedback given to developers before the session. Check what was last discussed and make sure to bring it up again. Also, include those that were you tracking during this time and connect them with the previous feedback process. Look for metrics such as pull request activity, work progress, team velocity, work log, check-ins, and more to get in-depth insights about their work. You can also gather peer reviews to get 360-degree feedback and understand better how well individuals are performing.

This makes your feedback balanced and takes into account all aspects of developers’ contributions and challenges.

During the feedback session

Two-way feedback

The feedback shouldn’t be a top-down approach. It must go both ways. You can start by bringing up the discussion that happened in the previous feedback session. Know their opinion and perspective on certain topics and ideas. Make sure that you ask questions to make them realize that you respect their opinions and want to hear what they want to discuss.

Now, share your feedback based on the last discussion, observations, and performance. You can also modify your feedback based on their perspective and reflections. It allows the feedback to be detailed and comprehensive.

Establish clear steps for improvement

When you have shared their areas of improvement, make sure you provide them with clear actionable plans as well. Discuss with them what needs immediate attention and what steps can they take. Set small goals with them as it makes it easier to focus on them and let them know that their goals are important. You must also schedule follow-up meetings with them after they reach every step and understand if they are facing any challenges. You can also provide resources and tools that can help them attain their goals.

Apply the SBI framework

Developed by the Center for Creative Leadership, the SBI stands for situation, behavior, and impact framework. It includes:

  • Situation: First, describe the specific context or scenario in which the observation/behavior took place. Provide factual details and avoid vague descriptions.

Example: Last week’s team collaboration on the new feature development.

  • Behavior: Now, articulate specific behavior you observed or experienced during that situation. Focus only on tangible actions or words instead of assumptions or generalizations.

Example: “You did not participate actively in the brainstorming sessions and missed a few important meetings.”

  • Impact: Lastly, explain the impact of behavior on you or others involved. Share the consequences on the team, project, and the organization.

Example: “This led to a lack of input from your side, and we missed out on potentially valuable ideas. It also caused some delays as we had to reschedule discussions.”

Final words could be: “Please ensure to attend all relevant meetings and actively participate in discussions. Your contributions are important to the team.”

This allows for delivering feedback that is clear, actionable, and respectful. It makes it relevant and directly tied to the situation. Note that, this framework is for both positive and negative feedback.

Understand constraints and personal circumstances

It is also important to know if any constraints are negatively impacting their performance. It could include tight deadlines or a heavy workload that is hampering their productivity or facing health issues due to which they aren’t able to focus properly. Ask them while you deliver feedback to them. You can further create actionable plans accordingly. This shows developers that you care for them and makes the feedback more personalized and relevant. Besides this, it also allows you to share tangible improvements rather than adding more pressure.

For example: “During the last sprint, there were a few missed deadlines. Is there something outside of work that might be affecting your ability to meet these deadlines? Please let me know if there’s anything we can do to accommodate your situation.”

Ask them if there’s anything else to discuss and summarize the feedback

Before concluding the meeting, ask them if there’s anything they would like to discuss. It could likely be that they have missed out on something or it wasn’t bought up during the session.

Afterwards, summarize what has been discussed. Ask the developers what are their key takeaways from the session and share your perspective as well. You can document the summary to help you and developers in the future feedback meetings. This gives mutual understanding and ensures that both are on the same page.

After the feedback session

Write a summary for yourself

Keep a record of what was discussed during this session and action plans provided to the developers. You can take a look at them in future feedback meetings or performance evaluations. An example of the structure of summary:

  • Date and time
  • List the main topics and specific behaviors discussed.
  • Include any constraints, personal circumstances, or insights the developer shared.
  • Outline the specific actions, along with any support or resources you committed to providing.
  • Detail the agreed-upon timeline for follow-up meetings or check-ins to monitor progress.
  • Add any personal observations or reflections that might help in future interactions.

Monitor the progress

Ensure you give them measurable goals and timelines during the feedback session. Monitor their progress through check-ins, provide ongoing support and guidance, and keep discussing the challenges or roadblocks they are facing. It helps the developers stay on track and feel supported throughout their journey.

How Typo can help enhance the feedback process?

Typo is an effective software engineering intelligence platform that can help in improving the feedback process within development teams. Here’s how Typo’s features can be leveraged to enhance feedback sessions:

  • By providing visibility into key SDLC metrics, engineering managers can give more precise and data-driven feedback.
  • It also captures qualitative insights and provides a 360-degree view of the developer experience allowing managers to understand the real issues developers face.
  • Comparing the team’s performance across industry benchmarks can help in understanding where the developers stand.
  • Customizable dashboards allow teams to focus on the most relevant metrics, ensuring feedback is aligned with the team’s specific goals and challenges.
  • The sprint analysis feature tracks and analyzes the progress throughout a sprint, making it easier to identify bottlenecks and areas for improvement. This makes the feedback more timely and targeted.
Typo can help enhance the feedback process
Typo can help enhance the feedback process

For more information, visit our website!


Software developers deserve high-quality feedback. It not only helps them identify their blind spots but also polishes their skills. The feedback loop lets developers know where they stand and the recognition they deserve.

Building and structuring an effective engineering team

Building a high-performing engineering team is crucial for the success of any company, especially in the dynamic and constantly evolving world of technology. Whether you’re a startup on the rise or an established enterprise looking to maintain your competitive edge, having a well-structured engineering team is essential.

This blog will explore the intricacies of building and structuring engineering teams for scale and success. We’ll cover many topics, including talent acquisition, skill development, team management, and more.

Whether you’re a CTO, a team leader, or an entrepreneur looking to build your own engineering team, this blog will equip you with the knowledge and tools to create a high-performing engineering team that can drive innovation and help you achieve your business goals.

What are the dynamics of engineering teams?

Before we dive into the specifics of team structure, it’s vital to understand the dynamics that shape engineering teams. Various factors, including team size, communication channels, leadership style, and cultural fit, influence these dynamics. Each factor plays a significant role in determining how well a team operates.

Team size

The size of a team can significantly impact its operation. Smaller teams tend to be more agile and flexible, making it easier for them to make quick decisions and respond to project changes. On the other hand, larger teams can provide more resources, skills, and knowledge, but they may struggle with communication and coordination.

Communication channels

Effective communication is essential for any team’s success. In engineering teams, communication channels play a significant role in ensuring team members can collaborate effectively. Different communication channels, such as email, chat, video conferencing, or face-to-face, can impact the team’s effectiveness.

Leadership style

A team leader’s leadership style can significantly impact the team’s effectiveness. Autocratic leaders tend to make decisions without input from team members, while democratic leaders encourage team members to participate in decision-making. Moreover, transformational leaders inspire and motivate team members to achieve their best.

Cultural fit

Cultural fit refers to how well team members align with the team’s values, norms, and beliefs. A team that has members with similar values and beliefs is more likely to work well together and be more productive. In contrast, a team with members with conflicting values and beliefs may struggle to work effectively.

Scaling engineering teams can present challenges, and planning and strategizing thoughtfully is crucial to ensure that the team remains effective. Understanding the dynamics that shape engineering teams can help teams overcome these challenges and work together effectively.

Key roles in engineering teams

An engineering team must be diverse and collaborative. Each team member should specialize in a particular area but also be able to comprehend and collaborate with others in building a product.

A few of them include:

Software development team lead and manager

The software development team lead plays a crucial role in guiding and coordinating the efforts of the software development team. They could have under 10 to hundreds of team members under their lead.

Software developer

Software developers write the code, their job is purely technical and they build the product. Most of them are individual contributors i.e. they have no management or HR responsibilities.

Product managers

Product managers define the product vision, gather and prioritize requirements, and deal with collaboration with engineering teams.


Designers create user-friendly interfaces, develop prototypes to visualize concepts and iterate on feedback-based designs.

Key principles for building and structuring engineering teams

Once the dynamics of engineering teams are understood, organizations can apply key principles to build and structure teams for scale. From defining goals and establishing role clarity to fostering a culture of collaboration and innovation, these principles serve as a foundation for effective team building.

  • Setting clear goals ensures everyone is aligned and working towards the same vision.
  • Clearly defined roles and responsibilities help prevent confusion and promote accountability within the team.
  • Foster an environment where team members feel empowered to collaborate, share ideas, and innovate.
  • Communication is the backbone of any successful team. Establishing efficient communication channels is vital for sharing information and maintaining transparency.
  • Encourage continuous learning and professional development to keep your team members motivated and up-to-date with the latest technologies and trends.
  • Allow individual team members autonomy while ensuring alignment with the organization’s overall goals and objectives.

Different approaches to structuring engineering teams

There is no one-size-fits-all approach to structuring engineering teams. Different structures may be more suitable depending on the organization’s size, industry, and goals. Organizations can identify the structure that best aligns with their unique needs and objectives by exploring various approaches.

The top two approaches are:

Project-based structure

When teams are formed based on the project for a defined period. It is a traditional way where engineers and designers are selected from their respective departments and tasked with project-related work.

It may seem logical, but it poses challenges. Project-based teams can prioritize short-term objectives and collaborating with unfamiliar team members can lead to communication gaps, particularly between developers and other project stakeholders.

Product-based structure

When teams are aligned around specific products or features to promote ownership and accountability. Since this team structure is centered around the product,  it is a long-term project, and team members are bound to work together more efficiently.

As the product gains traction and attracts users, the team needs to adapt to a changing environment i.e. restructuring and hiring specialists.

Other approaches include:

  • Functional-based structure: Organizing teams based on specialized functions such as backend, frontend, or QA.
  • Matrix-based structure: Combining functional and product-based structures to leverage expertise and resources efficiently.
  • Hybrid models: Tailoring the team structure to fit your organization’s unique needs and challenges.

Top pain points in building engineering teams

Sharing responsibilities

In engineering organizations, there is a tendency to rely heavily on one person for all responsibilities rather than distributing them among team members. It not only leads to bottlenecks and inefficiencies but also, slows down progress and the inability to deliver quality products.

Broken communication

The two most common communication issues while structuring and building engineering teams are – Alignment and context-switching between engineering teams. This increases the miscommunication among team members and leads to duplication of work, neglected responsibilities, and coverage gaps.

Lack of independence

When engineering leaders micromanage developers, it can hinder productivity, innovation, and overall team effectiveness. Hence, having a structure that fosters optimization, ownership, and effectiveness is important for building an effective team.

Best practices for scaling engineering teams

Scaling an engineering team requires careful planning and execution. Here are the best practices to build a team that scales well:

  • Streamline your hiring and onboarding processes to attract top talent and integrate new team members seamlessly.
  • Develop scalable processes and workflows to accommodate growth and maintain efficiency.
  • Foster a diverse and inclusive workplace culture to attract and retain top talent from all backgrounds.
  • Invest in the right tools and technologies to streamline development workflows and enhance collaboration.
  • Continuously evaluate your team structure and processes, making adjustments as necessary to adapt to changing needs and challenges.

Build an engineering team that sets your team up for success!

Building and structuring engineering teams for scale is a multifaceted endeavor that requires careful planning, execution, and adaptation.

But this doesn’t end here! Measuring a team’s performance is equally important to build an effective team. This is where Typo comes in!

It is an intelligent engineering management platform used for gaining visibility, removing blockers, and maximizing developer effectiveness. It gives a comparative view of each team’s performance across velocity, quality, and throughput.

engineering management platform

Key features

  • Seamlessly integrates with third-party applications such as Git, Slack, Calenders, and CI/CD tools.
  • ‘Sprint analysis’ feature allows for tracking and analyzing the team’s progress throughout a sprint.
  • Offers customized DORA metrics and other engineering metrics that can be configured in a single dashboard.
  • Offers engineering benchmark to compare the team’s results across industries.
  • User-friendly interface.

For more information, check out our website!

Iteration burndown chart: Tips for effective use

Agile project management relies on iterative development cycles to deliver value efficiently. Central to this methodology is the iteration burndown chart, a visual representation of work progress over time. In this blog, we’ll explore leveraging and enhancing the iteration burndown chart to optimize Agile project outcomes and team collaboration.

What is an iteration burndown chart?

An iteration burndown chart is a graphical representation of the total work remaining over time in an Agile iteration, helping teams visualize progress toward completing their planned work.

 iteration burndown chart


It typically includes an ideal line representing the planned progress, an actual line indicating the real progress, and axes to represent time and work remaining.


The chart enables teams to monitor their velocity, identify potential bottlenecks, and make data-driven decisions to ensure successful iteration completion.

Benefits of using iteration burndown charts

Understanding the advantages of iteration burndown charts is key to appreciating their value in Agile project management. From enhanced visibility to improved decision-making, these charts offer numerous benefits that can positively impact project outcomes.

  • Improved visibility: provides stakeholders with a clear view of project progress.
  • Early risk identification: helps identify and address issues early in the iteration.
  • Enhanced communication: facilitates transparent communication within the team and with stakeholders.
  • Data-driven decisions: enables teams to make informed decisions based on real-time progress data.

How to create an effective iteration burndown chart

Crafting an effective iteration burndown chart requires a thorough and step-by-step approach. Here are some detailed guidelines to help you create a well-designed burndown chart that accurately reflects progress and facilitates efficient project management:

  • Set clear goals: Before you start creating your chart, it’s essential to define clear objectives and expectations for the iteration. Be specific about what you want to achieve, what tasks need to be completed, and what resources you’ll need to get there.
  • Break down tasks: Once you’ve established your goals, you’ll need to break down tasks into manageable units to track progress effectively. Divide the work into smaller tasks that can be completed within a reasonable timeframe and assign them to team members accordingly.
  • Accurate estimation: Accurate estimation of effort required for each task is crucial for creating an effective burndown chart. Make sure to involve team members in the estimation process, and use historical data to improve accuracy. This will help you to determine how much work is left to be done and when the iteration will be completed.
  • Choose the right tools: Creating an effective burndown chart requires selecting the appropriate tools for tracking and visualizing data. Typo is a great option for creating and managing burndown charts, as it allows you to customize the chart’s appearance and track progress in real time.
  • Regular updates: Updating the chart regularly is essential for keeping track of progress and making necessary adjustments. Set a regular schedule for updating the chart, and ensure that team members are aware of the latest updates. This will help you to identify potential issues early on and adjust the plan accordingly.

By following these detailed guidelines, you’ll be able to create an accurate and effective iteration burndown chart that can help you and your team monitor your project’s progress and manage it more efficiently.

Tips for using iteration burndown charts effectively

While creating a burndown chart is a crucial first step, maximizing its effectiveness requires ongoing attention and refinement. These tips will help you harness the full potential of your iteration burndown chart, empowering your development teams to achieve greater success in Agile projects.

  • Simplicity: keep the chart simple and easy to understand.
  • Consistency: use consistent data and metrics for accurate analysis.
  • Collaboration: encourage team collaboration and transparency in updating the chart.
  • Analytical approach: analyze trends and patterns to identify areas for improvement.
  • Adaptability: adjust the chart based on feedback and lessons learned during the iteration.

Improving your iteration burndown chart

Continuous improvement lies at the heart of Agile methodology, and your iteration burndown chart is no exception. By incorporating feedback, analyzing historical data, and experimenting with different approaches, you can refine your chart to better meet your team’s and stakeholders’ needs.

  • Review historical data: analyze past iterations to identify trends and improve future performance.
  • Incorporate feedback: gather input from team members and stakeholders to refine the chart’s effectiveness.
  • Experiment with formats: try different chart formats and visualizations to find what works best for your team.
  • Additional metrics: integrate additional metrics to provide deeper insights into project progress.

Are iteration burndown charts worth it?

A burndown chart is great for evaluating the ratio of work remaining and the time it takes to complete the work. However, relying solely on a burndown chart is not the right way due to certain limitations.

Time-consuming and manual process

Although creating a burndown chart in Excel is easy, entering data manually requires more time and effort. This makes the work repetitive and tiresome after a certain point.

Unable to give insights into the types of issues

The Burndown chart helps to track the progress of completing tasks or user stories over time within a sprint or iteration. But, it doesn’t provide insights about the specific types of issues or tasks being worked on. It includes shipping new features, determining technical debt, and so on.

Gives equal weight to all the tasks

A burndown chart doesn’t differentiate between an easy and difficult task. It considers all of them equal, regardless of their size, complexity, or effort required to complete it. Hence, leading to ineffective outlines of project progress. This further potentially masks critical issues and hinders project management efforts.

Unable to give complete information on sprint predictability

The burndown chart primarily focuses on tracking remaining work throughout a sprint, but it doesn’t directly indicate the predictability of completing that work within the sprint timeframe. It lacks insight into factors like team velocity fluctuations or scope changes, which are crucial for assessing sprint predictability accurately.

How does Typo leverage the sprint predictability?

Typo’s sprint analysis is an essential tool for any team using an agile development methodology. It allows agile teams to track and analyze overall progress throughout a sprint timeline.  It helps to gain visual insights into how much work has been completed, how much work is still in progress, and how much time is left in the sprint. This information can help to identify any potential problems early on and take corrective action.

sprint predictability

Our sprint analysis feature uses data from Git and issue management tools to provide insights into how software development teams are working. They can see how long tasks are taking, how often they’re being blocked, and where bottlenecks are occurring.

It is easy to use and can be integrated with existing Git and Jira/Linear/Clickup workflows.

Key features

  • A velocity chart shows how much work has been completed in previous sprints.
  • A sprint backlog that shows all of the work that needs to be completed in the sprint.
  • A list of sprint issues that shows the status of each issue.
  • Time tracking to see how long tasks are taking.
  • Blockage tracking to check how often tasks are being blocked, and what are the causes of those blocks.
  • Bottleneck identification to identify areas where work is slowing down.
  • Historical data analysis to compare sprint data over time.
sprint predictability

Constantly improve your charts!

The iteration burndown chart is a vital tool in Agile project management. It offers agile and scrum teams a clear, concise way to track progress and make data-driven decisions.

However, one shouldn’t rely solely on the burndown charts. Moreover, there are various advanced sprint analysis tools such as Typo in the market that allow teams to track and gain visual insights into the overall progress of the work.

What are Jira Dashboards and How to Create it?

Jira is a widely used project management tool that enables teams to work together efficiently and achieve outstanding outcomes. The Jira dashboard is a vital component of this tool, offering teams valuable insights, metrics, and project visibility. In this journey, we will explore the potential of Jira dashboards and learn how to leverage their full capabilities.

What is a Jira Dashboard?

A Jira dashboard serves as the nerve center of project activity, offering a consolidated view of tasks, progress, and key metrics. It gives stakeholders a centralized location to monitor project health, track progress, and make informed decisions.

Jira Core dashboard: your project status at a glance

What are the Components of a Jira Dashboard?


These modular components provide specific information and functionality, such as task lists, burndown charts, and activity streams. There are several gadgets built into Jira such as filter results gadget, issue statistics gadget, and road map gadget. However, additional gadgets can also be downloaded from the Atlassian Marketplace. Some of them are the pivot gadget and gauge gadget.


Jira dashboards host various reports, including velocity charts, sprint summaries, and issue statistics, offering valuable insights into team performance,  and project trends.

Why is it Used?

Jira dashboards are used for several reasons:

  • Visibility: Dashboards offer stakeholders a real-time snapshot of project status and progress, promoting transparency and accountability.
  • Decision Making: By providing access to actionable insights and performance metrics, dashboards enable data-driven decision-making, leading to more informed choices.
  • Collaboration: Dashboards foster collaboration by providing a centralized platform for teams to track tasks, share updates and communicate effectively.
  • Efficiency: Dashboards streamline project management processes and enhance team productivity by consolidating project information and metrics in one location.

The default Jira dashboard

The default dashboard is also known as the system dashboard. It is the screen Jira users see the first time they log in. It includes gadgets from Jira’s pre-installed selection and is limited to only one dashboard page.

Creating your Jira dashboard

Creating custom dashboards requires careful planning and consideration of project objectives and team requirements. Let’s explore the step-by-step process of crafting a bespoke dashboard:

Create a New Dashboard

Log in to your Jira account. Go to the dashboard and click ‘Create Dashboard’.

Define Dashboard Objectives

Start by defining the objectives and goals of your dashboard page. Determine what information is crucial for your team to track and monitor, and tailor your dashboard accordingly.

Select Relevant Gadgets and Reports

Choose gadgets and reports that align with your project’s needs and objectives. When curating your dashboard content, consider factors such as team workflow, project complexity, and stakeholder requirements.

Opt for your Preferred Layout and Configuration

Choose your preferred dashboard layout and configuration to ensure optimal visibility and usability for all stakeholders. Arrange gadgets and reports logically and intuitively to facilitate easy navigation and information access.

Iterative Refinement

Embrace an iterative dashboard refinement approach. Solicit user and stakeholder feedback to improve its effectiveness and usability continuously. Regularly assess and update your dashboard to reflect evolving project needs and priorities.

Share the Dashboard with Team Members

Don’t forget to share the Jira dashboard with the team. This ensures transparency and fosters a collaborative culture. By granting appropriate permissions, they can view and interact with the dashboard and get real-time updates.

JIRA Dashboard Examples

Personal Dashboard

A personal dashboard is tailored to individual needs and offers various advantages in streamlining workflow management and improving productivity. It provides a centralized platform for organizing and visualizing user’s tasks, different projects, issues, etc.

Sprint Burndown Dashboard

This dashboard gives real-time updates on whether the team is on pace to meet a sprint goal. It offers a glimpse of how much work is left in the queue and how long your team will take to complete it. Moreover, the sprint burndown dashboard allows you to jump on any issue when the remaining workload is pacing slower than the delivery date.

Workload Dashboard

The workload dashboard, also known as the monitor resource dashboard tracks the amount of work assigned to each team member and adjusts their workload accordingly. It helps identify workload patterns and plan resource allocation.

Issue Tracking Dashboard

The issue tracking dashboard allows users to quickly identify and prioritize the most important issues. It focuses on providing visibility into the status and progress of issues or tickets within a project.

Maximizing Dashboard Impact

To maximize the impact of your Jira dashboard, consider the following best practices:

Promote Transparency and Collaboration

Share your dashboard with relevant stakeholders to promote transparency and collaboration. Encourage team members to actively engage with the dashboard and provide feedback to drive continuous improvement.

Leverage Automation and Integration

Integrating your Jira dashboard with other tools and systems is the best way to automate data capture and reporting processes. Leverage integration capabilities to streamline workflow management and enhance productivity.

Foster Data-Driven Decision Making

Empower project teams and leaders to make informed decisions by providing access to actionable insights and performance metrics through the dashboard. Encourage data-driven discussions and decision-making to drive project success.

Advanced dashboard customization

Take your Jira dashboard customization to the next level with advanced techniques and strategies:

Dashboard Filters and Contextualization

Implement filters and contextualization techniques to personalize the dashboard experience for individual users or specific project phases. Allow users to tailor the dashboard view based on their preferences and requirements.

Dynamic Dashboard Updates

Utilize dynamic updating capabilities to ensure that your dashboard reflects real-time changes and updates in project data. Implement automated refresh intervals and notifications to keep stakeholders informed and engaged.

Custom Gadgets and Extensions

Explore the possibilities of custom gadgets and extensions to extend the functionality of your Jira dashboard. Develop custom gadgets or integrate third-party extensions to address unique project requirements and enhance user experience.

How Typo's Sprint Analysis Feature is Useful for the Jira Dashboard?

Typo’s sprint analysis feature can be seamlessly integrated with the Jira dashboard. It allows to track and analyze the team’s progress throughout a sprint and provides valuable insights into work progress, work breakup, team velocity, developer workload, and issue cycle time.

The benefits of Sprint analysis feature are:

  • It helps spot potential issues early, allowing for corrective action to avoid major problems.
  • Pinpointing inefficiencies, such as excessive time spent on tasks, enables workflow improvements to boost team productivity.
  • Provides real-time progress updates, ensuring deadlines are met by highlighting areas needing adjustments.

The better Way to Achieve Project Excellence

A well-designed Jira dashboard is a catalyst for project excellence, providing teams with the insights and visibility they need to succeed. By understanding its components, crafting a tailored dashboard, and maximizing its impact, you can unlock Jira dashboards’ full potential and drive your projects toward success.

Furthermore, while Jira dashboards offer extensive functionalities, it’s essential to explore alternative tools that may simplify the process and enhance user experience. Typo is one such tool that streamlines project management by offering intuitive dashboard creation, seamless integration, and a user-friendly interface. With Typo, teams can effortlessly visualize project data, track progress, and collaborate effectively, ultimately leading to improved productivity and project outcomes. Explore Typo today and revolutionize your project management experience.

How to fix scrum anti patterns?

Scrum has become one of the most popular project management frameworks, but like any methodology, it’s not without its challenges. Scrum anti-patterns are common obstacles that teams may face, leading to decreased productivity, low morale, and project failure. Let’s explore the most prevalent Scrum anti patterns and provide practical solutions to overcome them.

Lack of clear definition of done

A lack of a clear Definition of Done (DoD) can cause teams to struggle to deliver shippable increments at the end of each sprint. It can be due to a lack of communication and transparency. This ambiguity leads to rework and dissatisfaction among stakeholders.


Collaboration is key to establishing a robust DoD. Scrum team members should work together to define clear criteria for completing each user story. These criteria should encompass all necessary steps, from development to testing and acceptance. The DoD should be regularly reviewed and refined to adapt to evolving project needs and ensure stakeholder satisfaction.

Overcommitting in sprint planning

One of the common anti patterns is overcommitment during sprint planning meetings. It sets unrealistic expectations, leading to compromised quality and missed deadlines.


Base sprint commitments on past performance and team capacity rather than wishful thinking. Focus on realistic sprint goal setting to ensure the team can deliver commitments consistently. Emphasize the importance of transparency and communication in setting and adjusting sprint goals.

Micromanagement by the scrum master

Micromanagement stifles team autonomy and creativity, leading to disengagement, lack of trust and reduced productivity.


Scrum Masters should adopt a servant-leadership approach, empowering teams to self-organize and make decisions autonomously. They should foster a culture of trust and collaboration where team members feel comfortable taking ownership of their work. They should provide support and guidance when needed, but avoid dictating tasks or solutions.

Lack of product owner engagement

Disengaged Product Owners fail to provide clear direction and effectively prioritize the product backlog, leading to confusion and inefficiency.


Encourage regular communication and collaboration between the Product Owner and the development team. Ensure that the Product Owner is actively involved in sprint planning, backlog refinement, and sprint reviews. Establish clear channels for feedback and decision-making to ensure alignment with project goals and stakeholder expectations.

Failure to adapt and improve

Failing to embrace a mindset of continuous improvement and adaptation leads to stagnation and inefficiency.


Prioritize retrospectives and experimentation to identify areas for improvement. Encourage a culture of learning and innovation where team members feel empowered to suggest and implement changes. Emphasize the importance of feedback loops and iterative development to drive continuous improvement and adaptation.

Scope creep

Allowing the project scope to expand unchecked during the sprint leads to incomplete work and missed deadlines.


Define a clear product vision and prioritize features based on value and feasibility. Review and refine the product backlog regularly to ensure that it reflects the most valuable and achievable items. Encourage stakeholder collaboration and feedback to validate assumptions and manage expectations.

Lack of cross-functional collaboration

Siloed teams hinder communication and collaboration, leading to bottlenecks and inefficiencies.


Foster a collaboration and knowledge-sharing culture across teams and disciplines. Encourage cross-functional teams to work together towards common goals. Implement practices such as pair programming, code reviews, and knowledge-sharing sessions to facilitate collaboration and break down silos.

Inadequate Sprint review and retrospective

Rushing through sprint retrospective and review meetings results in missed opportunities for feedback and improvement.


Allocate sufficient time for thorough discussion and reflection during sprint review and retrospective meetings. Encourage open and honest communication and ensure that all development team members have a chance to share their insights and observations. Based on feedback and retrospective findings, prioritize action items for continuous improvement.

Unrealistic commitments by the product owner

Product Owners making unrealistic commitments disrupt the team’s focus and cause delays.


Establish a clear process for managing changes to the product backlog. Encourage collaboration between the Product Owner and the development team to negotiate realistic commitments and minimize disruptions during the sprint. Prioritize backlog items based on value and effort to ensure the team consistently delivers on its commitments.

Lack of stakeholder involvement

Limited involvement or feedback from stakeholders leads to misunderstandings and dissatisfaction with the final product.


Engage stakeholders early and often throughout the project lifecycle. Solicit feedback and involve stakeholders in key decision-making processes. Communicate project progress regularly and solicit input to ensure alignment with stakeholder expectations and requirements.

Ignoring technical debt

Neglecting to address technical debt results in decreased code quality, increased bugs, and slower development velocity over time.


Allocate time during each sprint for addressing technical debt alongside new feature development. Encourage collaboration between developers and stakeholders to prioritize and tackle technical debt incrementally. Invest in automated testing and refactoring to maintain code quality and reduce technical debt accumulation.

Lack of continuous integration and deployment

Failing to implement continuous integration and deployment practices leads to integration issues, longer release cycles, and reduced agility.


Establish automated CI/CD pipelines to ensure that code changes are integrated and deployed frequently and reliably. Invest in infrastructure and tools that support automated testing and deployment. Encourage a culture of automation and DevOps practices to streamline the development and delivery process.

Daily scrum meetings are inefficient

Daily scrum meeting is usually used synonymously with daily status meetings. This loses its focus on collaboration and decision-making. Sometimes, team members don’t find any value in these meetings leading to disengagement and decreased motivation.


In daily scrums, the focus should only be on talking to each other about what’s the most important work to get done that day and how to do it. Encourage team members to collaborate to tackle problems and achieve sprint goals. Moreover, keep the daily scrums short and timeboxed, typically to 15 minutes.

Navigating scrum challenges with confidence

Successfully implementing Scrum requires more than just following the framework—it demands a keen understanding of potential pitfalls and proactive strategies to overcome them. By addressing common Scrum anti patterns, teams can cultivate a culture of collaboration, efficiency, and continuous improvement, leading to better project outcomes and stakeholder satisfaction.

However, without the right tools, identifying and addressing these anti-patterns can be daunting. That’s where Typo comes in. Typo is an intuitive project management platform designed to streamline Agile processes, enhance team communication, and mitigate common Scrum challenges.

With Typo, teams can effortlessly manage their Scrum projects, identify and address anti-patterns in real-time, and achieve greater success in their Agile endeavors.

So why wait? Try Typo today and elevate your Scrum experience to new heights!

How to Improve Your Jira Ticket Management?

Jira software has become the backbone of project management for many teams across various industries. Its flexibility and powerful features make it an invaluable tool for organizing tasks, tracking progress, and collaborating effectively. However, maximizing its potential requires more than just basic knowledge. To truly excel in Jira ticket management, you must implement strategies and best practices that streamline your workflows and enhance productivity.

What is Jira Ticket Management?

Jira is a popular project management tool developed by Atlassian, commonly used for issue tracking, bug tracking, and project management. Jira ticket management refers to the process of creating, updating, assigning, prioritizing, and tracking issues within Jira.

Jira Service Desk | IT Service Desk & ITSM Software

Key Challenges in Jira Ticketing System

Requires Significant Manual Work

One of the major challenges with Jira ticketing platform is that it requires a lot of tedious and manual work.  This leads to developer frustration, incomplete ticket updates, and undocumented work.

Complexity of Configuration

Setting up Jira software to align with the specific needs of a team or project can be complicated. Configuring workflows, custom fields, and permissions requires careful planning and may involve a learning curve for administrators.

Lacks Data Hygiene

Due to the above-mentioned points, it can lead to software development team work becoming untracked and invisible. Hence, the team lacks data hygiene which further leads top management to make decisions with incomplete information. This can further impact planning accuracy as well.

How to Manage JIRA Tickets Better?

Below are some essential tips to help you manage your Jira tickets better:

JIRA Automations

Developers often find it labor-intensive to keep tickets updated. Hence, JIRA provides some automation that eases the work of developers. Although these automations are a bit complex initially, once mastered, they offer significant efficiency gains. Moreover, they can be customized as well.

Here are a few JIRA automation that you can take note of:

Smart Auto Design

This is one of the most commonly used automation that involves ensuring accountability for an issue by automatically assigning it to its creator. It ensures that there is always a designated individual responsible for addressing the matter, streamlining workflow management and accountability within the team.

Auto-Create Sub-Tasks

This automation can be customized to suit various scenarios, such as applying it to epics and stories or refining it with specific conditions tailored to your workflow. For example, when a bug issue is reported, you can set up automation to automatically create tasks aimed at resolving the problem. It not only streamlines the process but also ensures that necessary tasks are promptly initiated, enhancing overall efficiency in issue management.

Clone Issues

Implementing this advanced automation involves creating a duplicate of an issue in a different project when it undergoes a specific transition. It also leaves a comment on the original issue to establish a connection between them. It becomes particularly valuable in scenarios where one project is dedicated to managing customer requests, while another project is focused on executing the actual work.

Change Due Date

This automation automatically computes and assigns a due date to an issue when it’s moved from the backlog to the ‘In Progress’ status.  This streamlines the process of managing task timelines, ensuring that deadlines are promptly established as tasks transition into active development stages.

Standardize Ticket Creation

Establishing clear guidelines for creating tickets ensures consistency across your projects. Include essential details such as a descriptive title, priority level, assignee, and due date. This ensures that everyone understands what needs to be done at a glance, reducing confusion and streamlining the workflow.

Moreover, standardizing ticket creation practices fosters alignment within your team and improves communication. When everyone follows the same format for ticket creation, it becomes easier to track progress, assign tasks, and prioritize work effectively. Consistency also enhances transparency, as stakeholders can quickly grasp the status of each ticket without needing to decipher varying formats.

Customize Workflows

Tailoring Jira workflows to match your team’s specific processes and requirements is essential for efficient ticket management. Whether you follow Agile, Scrum, Kanban, or a hybrid methodology, configure workflows that accurately reflect your workflow stages and transitions. This customization ensures your team can work seamlessly within Jira, optimizing productivity and collaboration.

Customizing workflows allows you to streamline your team’s unique processes and adapt to changing project needs. For example, you can define distinct stages for task assignment, development, testing, and deployment that reflect your team’s workflow. Custom workflows empower teams to work more efficiently by clarifying task progression and facilitating smoother handoffs between team members.

Prioritize Effectively

Not all tasks are created equal in Jira. Use priority fields to categorize tickets based on urgency and importance. This strategic prioritization helps your team focus on high-priority items and prevents critical tasks from slipping through the cracks. By prioritizing effectively, you can ensure that important deadlines are met and resources are allocated efficiently.

Effective prioritization involves considering various factors, such as project deadlines, stakeholder requirements, and resource availability. By assessing the impact and urgency of each task, teams can more effectively allocate their time and resources. Regularly reviewing and updating priorities ensures your team remains agile and responsive to changing project needs.

Utilize Labels and Tags

Leverage tags or custom fields to add context to your tickets. Whether it’s categorizing tasks by feature, department, or milestone, these metadata elements make it easier to filter and search for relevant tickets. By utilizing labels and tags effectively, you can improve organization and streamline ticket management within Jira.

Furthermore, consistent labeling conventions enhance collaboration and communication across teams. When everyone adopts a standardized approach to labeling tickets, it becomes simpler to locate specific tasks and understand their context. Moreover, labels and tags can provide valuable insights for reporting and analytics, enabling teams to track progress and identify trends over time.

Encourage Clear Communication

Effective communication is the cornerstone of successful project management. Encourage team members to provide detailed updates, ask questions, and collaborate openly within Jira ticket comments. This transparent communication ensures that everyone stays informed and aligned, fostering a collaborative environment conducive to productivity and success.

Clear communication within Jira ticket comments keeps team members informed and facilitates knowledge sharing and problem-solving. Encouraging open dialogue enables team members to provide feedback, offer assistance, and address potential roadblocks promptly. Additionally, documenting discussions within ticket comments provides valuable context for future reference, aiding in project continuity and decision-making.

Automate Repetitive Tasks

Identify repetitive tasks or processes and automate them using Jira’s built-in automation features or third-party integrations. This not only saves time but also reduces the likelihood of human error. By automating repetitive tasks, you can free up valuable resources and focus on more strategic initiatives, improving overall efficiency and productivity.

Moreover, automation can standardize workflows and enforce best practices, ensuring project consistency. By defining automated rules and triggers, teams can streamline repetitive processes such as task assignments, status updates, and notifications. This minimizes manual intervention and enables team members to devote their time and energy to tasks that require human judgment and creativity.

Regularly Review and Refine

Continuously reviewing your Jira setup and workflows is essential to identify areas for improvement. Solicit feedback from team members and stakeholders to understand pain points and make necessary adjustments. By regularly reviewing and refining your Jira configuration, you can optimize processes and adapt to evolving project requirements effectively.

Moreover, regular reviews foster a culture of continuous improvement within your team. By actively seeking feedback and incorporating suggestions for enhancement, you demonstrate a commitment to excellence and encourage team members to engage. Additionally, periodic reviews help identify bottlenecks and inefficiencies, allowing teams to address them proactively and maintain high productivity levels.

Integrate with Other Tools

Jira seamlessly integrates with a wide range of third-party tools and services, enhancing its capabilities and extending its functionality. Integrating with other tools can streamline your development process and enhance collaboration, whether it’s version control systems, CI/CD pipelines, or communication platforms. Incorporating workflow automation tools into the mix further enhances efficiency by automating repetitive tasks and reducing manual intervention, ultimately accelerating project delivery and reducing errors.

Furthermore, integrating Jira with other tools promotes cross-functional collaboration and data sharing. By connecting disparate systems and centralizing information within Jira, teams can eliminate silos and improve visibility into project progress. Additionally, integrating with complementary tools allows teams to leverage existing investments and build upon established workflows, maximizing efficiency and effectiveness.

Foster a Culture of Continuous Improvement

Encourage a mindset of continuous improvement within your software teams. Encourage feedback, experimentation, and learning from both successes and failures. By embracing a culture of constant improvement, you can adapt to changing requirements and drive greater efficiency in your Jira ticket management process while also building a robust knowledge base of best practices and lessons learned.

Moreover, fostering a culture of continuous improvement empowers team members to take ownership of their work and seek opportunities for growth and innovation. By encouraging experimentation and learning from failures, teams can cultivate resilience and agility, enabling them to thrive in dynamic environments. Additionally, celebrating successes and acknowledging contributions fosters morale and motivation, creating a positive and supportive work culture.

How these Strategies Can Help in Better Planning?

Better JIRA ticket management helps in improving planning accuracy. Below are a few of the ways how these strategies can further help in better planning:

  • Automating these tasks reduces the likelihood of human error and ensures that essential tasks are promptly initiated and tracked, leading to better planning accuracy.
  • Establishing clear guidelines for creating tickets reduces confusion and ensures that all necessary details are included from the start, facilitating more accurate planning and resource allocation.
  • Clear communication within JIRA comments ensures that everyone understands project requirements and updates, reducing misunderstandings and enhancing planning accuracy by facilitating effective coordination and decision-making.
  • Connecting disparate systems and centralizing information improves visibility into project progress and facilitates data sharing. Hence, improving planning by providing a comprehensive view of project status and dependencies.
  • When you consistently follow through on your commitments, you build trust not just within your own team, but across the entire company. Hence, allowing other teams to confidently line up their timelines to development timelines, leading to a tightly aligned, high-velocity organization.

Plan your Way into a Good Jira Ticket System!

Improving your Jira ticket management, essential for effective task management, requires thoughtful planning, ongoing refinement, and a commitment to best practices. Implementing these tips and fostering a culture of continuous improvement can optimize your workflows, enhance collaboration, and drive greater project success, benefiting both internal teams and external customers.

If you need further help in optimizing your engineering processes, Typo is here to help you.

Curious to know more? Learn about Typo here!

How to Create a Burndown Chart in Excel?

In Agile project management, it is crucial to get a clear picture of the project’s reality. Hence, one of the best ways is to visualize the progress.

A Burndown chart is a project management chart that shows the remaining work needed to reach project completion over time.

Let’s understand how can you create a burndown chart in Excel:

What is a Burndown Chart?

A Burndown chart visually represents teams’ or projects’ progress over time. It analyzes their pace, reflects progress, and determines if they are on track to complete it on time.

Burndown charts are generally of three types:

Product Burndown Chart

The product burndown chart focuses on the big picture and visualizes the entire project. It determines how many product goals the development team has achieved so far and the remaining work.

Sprint Burndown Chart

Sprint burndown charts focus on the ongoing sprints. It indicates progress towards completing the sprint backlog.

Epic Burndown Chart

This chart focuses on how your team is performing against the work in the epic over time. It helps to track the advancement of major deliverables within a project.

Components of Burndown Chart


A burndown chart has two axes: X and Y. The horizontal axis represents the time or iteration and the vertical axis displays user story points.

Ideal Work Remaining

It is the diagonal line sloping downwards that represents the remaining work a team has at a specific point of the project or sprint under ideal conditions.

Actual Work Remaining

It is a realistic depiction of the team’s performance that is updated in real-time. It is drawn as the teams progress and complete user stories.  

Story Points

Each point on the work lines displays a measurement of work remaining at a given time.

Project/Sprint End

It is the rightmost point of your burndown chart that represents whether the team has completed a project/sprint on time, behind, or ahead of schedule.

Benefits of Burndown Chart

Visual Representation of Work

A Burndown chart helps in keeping an eye on teams’ work progress visually. This is not only simple to use but also motivates the team to perform well.

Shows a Direct Comparison

A burndown chart is useful to show the direct comparison between planned work and actual progress over time. This helps in quickly assessing whether the team is on track to meet its goals.

Better Team Productivity

A burndown chart acts as a tool for inspiration. Such types of charts transparently show the progress and work efficiency. Hence, improving the collaboration and cooperation between team members.

Quickly Identifies or Spots Blockers

A burndown chart must be updated daily. This helps in tracking progress in real-time, identifying problems in early stages hence, assisting in completing the project on time.

How to Create a Burndown Chart in Excel?

Step 1: Create Your Table

Open a new sheet in Excel and create a new table that includes 3 columns.

The first column should include the dates of each sprint, the second column have the ideal burndown i.e. ideal rate at which work will be completed and the last column should have the actual burndown i.e. updating them as story points get completed.

Step 2: Add Data in these Columns

Now, fill in the data accordingly. This includes the dates of your sprints and numbers in the Ideal Burndown column indicating the desired number of tasks remaining after each day throughout the let’s say, 10-day sprint.

As you complete tasks each day, update the spreadsheet to document the number of tasks you can finish under the ‘Actual Burndown’ column.

Step 3: Create a Burndown Chart

Now, it’s time to convert the data into a graph. To create a chart, follow these steps: Select the three columns > Click ‘Insert’ on the menu bar > Select the ‘Line chart’ icon, and generate a line graph to visualize the different data points you have in your chart.

How to Use a Burndown Chart in the Best Possible Way?

Determine the Project Scope

Study project scope and divide the projects or sprints into short-term tasks. Ensure to review them and estimate the time required to complete each task based on the project deadline.

Check the Chart Often

The Scrum master must check the chart often and update it daily. It helps to understand the flagging trends, know the pitfalls, and ensure it aligns with the expectations.

Pay Attention to the Outcome

Don’t lose sight of the outcome. By focusing on it, software development teams can ensure they are making progress toward their goals and adjust their efforts accordingly to stay on track for successful project completion.

Don’t Put in Weekends

Teams pause the work during weekends or holidays. Excluding weekends provides accuracy by focusing solely on the days when active work is being done hence giving a clearer representation of progress and highlighting the team’s actual productivity levels during working days.

Encourage Team Ownership

Burndown chart, when accessible to the entire team, fosters collaboration and accountability. It gives them a sense of ownership to discuss points to address challenges and celebrate achievements.

Limitations of a Burndown Chart

A burndown chart is great for evaluating the ratio of work remaining and the time it takes to complete the work. However, relying solely on a burndown chart is not the right way due to certain limitations.

A Time-Consuming and Manual Process

Although creating a burndown chart in Excel is easy, entering data manually requires more time and effort. This makes the work repetitive and tiresome after a certain point.

There are various tools available in the market that offer collaboration and automation features including Jira, Trello, and Asana.

It Doesn’t Give Insights into the Types of Issues

The Burndown chart helps in tracking the progress of completing tasks or user stories over time within a sprint or iteration. But, it doesn’t provide insights about the specific types of issues or tasks being worked on. It includes shipping new features, determining technical debt, and so on.

It Gives Equal Weight to all the Tasks

A burndown chart doesn’t differentiate between an easy and difficult task. It considers all of them equal, regardless of their size, complexity, or effort required to complete it. Hence, leading to ineffective outlines of project progress. This further potentially masks critical issues and hinders project management efforts.

As a result, the burndown chart is not a reliable metric engineering leaders can solely trust. It is always better to complement it with sprint analysis tools to provide additional insights tailored to agile project management. A few of the reasons are stated below:

  • Sprint analysis software can offer a wider range of metrics such as velocity, cycle time, throughput, and cumulative flow diagrams to provide a more comprehensive understanding of team performance and process efficiency.
  • These tools typically offer customization options to tailor metrics and reports according to the team’s specific needs and preferences.
  • They are designed with Agile principles in mind which incorporate concepts such as iterative improvement, feedback loops, and continuous delivery.

Typo - An Effective Sprint Analysis Tool

Typo’s sprint analysis feature allows engineering leaders to track and analyze their team’s progress throughout a sprint. It uses data from Git and the issue management tool to provide insights into getting insights on how much work has been completed, how much work is still in progress, and how much time is left in the sprint hence, identifying any potential problems early on and taking corrective action.

Screenshot 2024-05-11 at 9.58.10 PM.png

Key Features:

  • A velocity chart shows how much work has been completed in previous sprints.
  • A sprint backlog that shows all of the work that needs to be completed in the sprint.
  • A list of sprint issues that shows the status of each issue.
  • Time tracking to See how long tasks are taking.
  • Blockage tracking to check how often tasks are being blocked, and what the causes of those blocks are.
  • Bottleneck identification to identify areas where work is slowing down.
  • Historical data analysis to compare sprint data over time.

How to Write Clean Code?

Martin Fowler once said “Anyone can write a code that a computer can understand. Good programmers write code that humans can understand.”

Clean code is an essential component of software development.

Writing clean code is exactly like a sales pitch. When you use words full of technical jargon, you end up losing your target audience. The same is true with coding as well. Writing clean code enhances the readability, maintainability, and understandability of the software.

What is Clean Code?

Robert C. Martin in his book “Clean Code: A Handbook of Agile Software Craftsmanship  defined clean code as:

“A code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have laid appropriate attention to details. They have cared.”

Clean code is clear, understandable, and maintainable. It is well-organized, properly documented, and follows standard conventions. The purpose behind clean code is to create software that is not just functional but readable and efficient throughout its lifecycle. Since the audience isn’t a computer but rather a real live audience.

Why is Clean Code Important?

Clean code is the foundation of sustainable software development. Below are a few reasons why clean code is important:

Reduce Technical Debt

Technical debt can slow down the development process in the long run. Having clean code ensures that future modifications will be smoother as well as less costly process.

Increase Code Readability and Maintainability

Clean code means that the developers are prioritizing clarity. When it is easier to read, understand, and modify code, it leads to faster software development.

Enhance Collaboration

Good code means that the code is accessible to all team members and follows coding standards. This helps in improved communication and collaboration among them.

Debugging and Issue Resolution

Clean code is designed with clarity and simplicity. Hence, making it easier to locate and understand specific sections of the codebase. This further helps in identifying and resolving issues in the early stages.

Ease of Testing

Clean code facilitates unit testing, integrated testing, and other forms of automated testing. Hence, leading to increased reliability and maintainability of the software.

Clean Code Principles and Best Practices

Below are some established clean code principles that most developers find useful.


Apply the KISS (Keep it simple, stupid) rule. It is one of the oldest principles of clean code. This means that don’t make the code unnecessarily complex. Make it as simple as possible. So that it takes less time to write, has less chance of bugs, easier to understand and modify.  

Curly’s Law

This law states that the entity (class, function, or variable) must have a single, defined goal. It should only do one thing in one circumstance.

DRY Rule

DRY (Don’t repeat yourself) is closely related to the KISS rule and Curly’s law. It states to avoid unnecessary repetition or duplication of code. Not following this can make the code prone to bugs and make the code change difficult.


YAGNI (You aren’t gonna need it) rule is an extreme programming practice that states that the developers shouldn’t add functionality unless deemed necessary. It should be used in conjunction with continuous refactoring, unit testing, and integration.

Fail Fast

It means that the code should fail as early as possible. This is because issues can be quickly identified and resolved which further limits the number of bugs that make it into production.

Boy Scout Rule

This rule by Uncle Bob states that always leave the code cleaner than you found it. It means that software developers must incrementally improve parts of the codebase they interact with, no matter how minute the enhancement might be.

SOLID Principles

Apply the SOLID principles. This refers to:

S: Single Responsibility Principle which means that the classes must only have a single responsibility.

O: The open-closed Principle states that the piece of software should be open for extension but closed for modification.

L: The Liskov Substitution Principle means that subclasses should be able to substitute their base class without getting incorrect results.

I: The Interface Segregation Principle states that interfaces should be specific to clients instead of being generic for all clients.

D: The dependency Inversion Principle means that classes should depend on abstractions (interfaces) rather than concrete implementations.

A few of the best practices include:

Use Descriptive and Meaningful Names

Choose descriptive and clear names for variables, functions, classes, and other identifiers. They should be easy to remember and according to the context that conveys the purpose and behavior to make the code understandable.

Follow Established Code-Writing Standards

Most programming languages have community-accepted coding standards and style guides. Some of them include Google Java style and PEP 8 for Python and Javascript. Organizations must also have internal coding rules and standards that provide guidelines for consistent formal, naming conventions and overall code organization.

Avoid Writing Unnecessary Comments

Comments help explain the code. However, the codebase changes continuously so the comment can become old or obsolete soon. This can create confusion and distraction among software developers. Make sure to keep the comments updated. Also, avoid writing poorly written or redundant comments as it may increase the cognitive load of software engineering teams.

Avoid Magic Numbers

Magic numbers are hard-coded numbers in code. They are considered to be a bad practice since they can cause ambiguity and confusion among developers. Instead of directly using them, create symbolic constants for hard-coded values. It makes it easy to change the value at a later stage and improves the readability and maintainability of the code.

Refactor Continuously

Ensure that you regularly refactor to enhance the structure and readability of the code. It also helps in improving its flexibility and maintaining code that is overly complex, poorly structured, or duplicated.

You can apply refactoring techniques such as extracting methods, renaming variables, and consolidating duplicate code to keep the codebase cleaner.

Version Control

Version control systems such as GIT, SVN, and Mercurial help track changes to your code and pull back to previous versions, if necessary. Before refactoring, ensure that the code is under version control to safely experiment with changes. Moreover, it helps understand the evolution of the project and maintains the integrity of the codebase by enforcing a structured workflow.

Git - About Version Control


Software developers can write unit tests to verify the code’s correctness as well-tested code is reliable and easier to refactor. Test-driven development helps in writing cleaner code as it considers edge cases and provides immediate feedback on code changes.

Code Reviews

Code reviewing continuously helps in ensuring code quality by identifying potential issues, catching bugs, and enforcing coding standards. It also facilitates collaboration between software developers to see each other’s strengths and review mistakes together.

Typo - An Automated Code Review Tool

Typo’s automated code review tool not only enables developers to catch issues related to code maintainability, readability, and potential bugs but also can detect code smells. It identifies issues in the code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps the code error-free, making the whole process faster and smoother.

Key features:

  • Supports top 10+ languages including JS, Python, Ruby
  • Understands the context of the code and fixes issues accurately
  • Optimizes code efficiently
  • Standardizes code and reduces the risk of a security breach
  • Provides automated debugging with detailed explanations


Writing clean code isn’t just a crucial skill for developers. It is an important way to sustain software development projects.

By following the above-mentioned principles and best practices, you can develop a habit of writing clean code. It will take time but it will be worth it in the end.

Hope this was helpful. All the best!

How to identify and remove dead code?

Dead code is the most overlooked aspect of software development projects. They can become common when they evolve. A large amount of dead code can be harmful to software.

The best way to ensure this is to detect dead code in the early stages to maintain the quality of the software application.

Let’s talk more about dead code below:

What is dead code?

Dead code can be referred to as the segment of code that is unnecessary for the software program. They are executed without their results being used or accessed.

Dead code is known as zombie code. Such a portion of code may have been part of earlier versions, experimental features, or functions that are no longer needed. If the dead code remains in the software, it can decrease the software’s efficiency and add unnecessary complexity to it. This can further make the code harder to understand and maintain.

Other types of dead code

Unreachable code

The segment of code that is never executed under any condition during program runtime. It could be due to conditional statements, loops, or other control flow structures. Besides this, the issue may even arise during development because of coding errors, incorrect logic, or unintended consequences of code refactoring.

Obsolete code

The portion of code that was once useful but not anymore. They have now become outdated or irrelevant due to changes in software requirements or function, technology, or best practices. Obsolete code may still be present in the codebase however, no longer recommended for use.

Orphaned code

Code that was once part of a functional feature or system but is now left behind or isolated. This can result from changes in project requirements, refactoring, feature removal, or other modifications in the development process. As obsolete code, this code may still be present but no longer integrated or contribute to the application functionality.

Commented out code

Sometimes, developers ‘comment out’ code rather than deleting it to use it in the future. However, when they forget about it, it can facilitate dead code. While it is a common practice, developers must take note of it otherwise it can reduce code readability and maintainability.

Why remove dead code?

Dead code majorly contributes to technical debt. While a small amount of technical debt is still fine, if it grows, it can negatively affect the team’s progress. This can also increase the delivery time to market to end-users and reduce customer satisfaction.

Hence, it is important to monitor technical debt through engineering metrics to take note of dead code as well.

Besides this, there are other reasons why removing dead code is crucial:

Improves maintainability

When dead code is present, it can complicate the understanding and maintenance of software systems. It can further lead to confusion and misunderstandings which increases the cognitive load of the engineering team.

Eliminating dead code lets them focus on relevant code that helps increase code readability, and facilitates feature updates and bug fixes.

Reduces security and risks

Dead code could be a hidden backdoor entry point to the system. This can be a threat to the security of the software. Moreover, dead code includes dependencies that are no longer needed.

Removing dead code simplifies code complexities, and improves code review and analysis processes. This further helps to address and reduce security vulnerabilities easily.

Decreases code and cognitive complexity

Dead code disrupts the understanding of codebase structure. It not only decreases the development process but also developers’ productivity and effectiveness.

Eliminating dead code results in reducing the overall size of the code. Hence, it makes it concise and easier to manage which potentially enhances developers’ performance.

Avoid code duplication

Duplicate code is a considerable strain on the software development process. However, when dead code is present, it diverts developers from identifying and addressing areas where code duplication occurs.

Hence, eliminating dead code avoids code duplication and improves the codebase’s quality.

Streamline development

When dead code is not present in the software, it allows developers to focus on the relevant active parts of the codebase. It also streamlines the process as there are no unnecessary distractions and identifies and addresses issues.

How to identify and remove dead code?

Static analysis tools

Dead code can often be removed through static code analysis tools. Automated tools such as code quality checkers can help in detecting unused variables, classes, imports, or modules. This allows developers to address and eliminate the dead code easily which reduces the development cost and improves the overall quality of the system.

However, the drawback is that during uncertainty regarding programming behavior, dead code may not be removed. Hence, static code analysis tools are not a complete solution.

Dynamic analysis tools

Dynamic code analysis tools involve running the program to see which lines are executed and identifying which code paths are never reached. Hence, the code that is never executed or used in the codebase i.e. dead code is eliminated.

However, most of these tools are specific to programming languages.

Version control history

Leverage version control systems such as GIT commits to identify code that was once active but now deprecated or replaced. Commits that were removed or modified could indicate areas where dead code be found.

In case of a mistake, the code can be retrieved from the version control system. Hence, less risky and easily manageable.


Through refactoring, developers carefully examine the codebase to identify sections that include unused or old code, unnecessary variables, functions, or classes. Hence, revealing dead code that can be safely removed. Moreover, refactoring aims to optimize code for performance, maintainability, and readability. This further allows developers to look out for inefficient or unnecessary code by replacing or redesigning these segments.

Code reviews

Code review is an effective method to maintain the quality of code. It promotes simplicity and clarity in the codebase. They can help in detecting dead code by applying best practices, standards, and conventions. However, when not automated, they can be time-consuming and harder to implement. Hence, it is recommended to use automated code review tools to speed up the process.

Typo - Automated code review tool

Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.

Key features:

  • Supports top 8 languages including C++ and C#
  • Understands the context of the code and fixes issues accurately
  • Optimizes code efficiently
  • Provides automated debugging with detailed explanations
  • Standardizes code and reduces the risk of a security breach
Typo - Automated code review tool

To learn more about this feature, click here!


In software engineering, detecting and removing dead code is imperative for streamlining the development process. You can choose the method or combination of methods to remove dead code that best aligns with your project’s needs, resources, and constraints.

All the best!

How Engineering Teams Can Optimize Their Calendars for Maximum Efficiency

Time is a finite resource. Once it is gone, you cannot alter it.

This is why the calendar plays a major role in organizing and focusing towards our goals. However, it can become cluttered and overwhelming, when done incorrectly. It not only affects the engineering teams but also impacts business and client experience negatively.

Hence, the optimization of calendars is important for both engineering managers and developers.

In this blog, let’s dive further into the art of calendar optimization and various time management techniques.

Importance of optimizing your calendar

Effective time management

Optimizing your calendar means making the most of your working hours. Effective time management allows you to create a micro plan for the day ahead and focus on high-priority tasks. Managing your time effectively reduces the risk of burnout and stress; helping in great productivity and alignment.

Project planning

Another importance of optimizing your calendar is that it helps in defining the project goals. When they are clearly outlined, it lets you align your schedules with the project needs. Breaking them down into smaller tasks lets you focus on them more effectively and tackle critical tasks first.

Greater focus and prioritization

Creating a daily schedule empowers you to spend more time on the project that matters and capture bigger opportunities. This further helps in prioritization and taking control of your day. Hence, reduces distractions and empowers you to do deep work.

Work-life balance

Another benefit of optimizing your calendar is achieving a work-life balance. You and your team get time for both personal and professional tasks. This helps in becoming more productive and reduces stress and feeling overwhelmed throughout the day.

Professional growth

When your priorities are set and have a clear schedule, it helps you deliver high-quality commits on time. It makes your team reliable and improves their professional reputation which further helps in their career growth.

Paul Graham: Maker schedule and manager schedule

In 2009, Paul Graham (co-founder of Y-Combinator), coined the terms – Maker schedule and Manager schedule. These are two different styles of working that require different approaches.

Let’s understand both these terms in detail:

Maker schedule and manager schedule

Maker schedule

The maker schedule is designed for individuals who need long, uninterrupted slots for focus time. It allows them to enter into the state of flow to achieve peak productivity. For the developers who require deep concentration, this type of schedule lets them fully immerse in projects and let the creativity flow.

How to set it?

Prioritize tasks:

First things first, create a to-do list. See which tasks need to be done solo and which need to be collaborated. Now, prioritize them according to their due dates. Communicate with other team members for the collaborative tasks.

Time blocking:

Set a specific time for deep work. You can add more than one per day since the tasks can stretch further. Use shorter blocks for meetings, communication, and other administrative tasks. Ensure that you communicate with others to minimize interruptions and distractions.

Batch different meetings together:

Bunch meetings such as team meetings, and one-on-one conversations together. However, schedule a 5-minute break between these meetings. This can reduce context switches and let you enter into a specific mental state. Hence, helps you with better concentration and productivity.

Take breaks:

Don’t forget to take short breaks between your slots. This can be anything ranging from short naps to exercise. This helps in maintaining focus and better retention of information. As a result, it increases your energy and prevents burnout.

Manager schedule

The manager schedule is for individuals who have various duties while handling teams and systems. It is usually for engineering managers and leaders since their day comprises meetings, managing teams, and their solo tasks as well. Their schedule is majorly based on coordinating with people who produce output. Hence, the schedule needs to be flexible yet maintain structure in their workflow.

How to set it?

Set a clear agenda for meetings:

Ensure that your meetings have clear goals and objectives. This helps minimize time wastage and keep discussions on track. Also, note that the meetings should be purposeful with a time limit. So, that they are straightforward and crisp.

Be mindful of others’ schedules:

Maker’s and manager’s schedules can contradict each other. Hence, have open communication about each other’s schedules. This allows everyone to not interrupt each other’s focus time and other important schedule. As a result, it reduces stress and pressure.

Integrate your personal calendar:

Make sure that you integrate your personal calendar as well so that your team knows when you are not available. It saves you and your team members from the trouble of rescheduling and streamlining planning without any stress.

Review and adjust:

Regularly review your schedule and adjust it accordingly. Check what’s working for you, and what can be delegated and eliminated. Align your time with evolving priorities and communicate the same with your team members.

How to balance manager and maker

In the current scenario, the maker schedule is difficult to follow in the organization. The culture is still meeting-heavy and prioritizes urgent and reactive tasks over deep work.

Below are a few of the ways to balance both approaches:

Use async communication

As the manager and maker schedules are different, async communication works better in this case. Tools like Slack and Microsoft Teams bridge the gap between these two frameworks. It creates an ecosystem where deep and creative work is prioritized yet allows you to be in regular contact with your team members without interruptions.

Assess existing meetings

Meetings that don’t have clear agendas and comes between your team members’ schedule need to be assessed. Review them regularly so that you know which of them are overlapping and can disrupt the workflow.

To make it easier to assess, you can ask yourself three questions:

  • Is this meeting necessary?
  • Who needs to attend this meeting?
  • Could this meeting be shorter and could it be communicated through written conversation?

Allow flexibility in the workplace

It is important to understand that creativity doesn’t always come at office hours. It can occur at different times and manners. Hence, communicate with your team members what are their focus time slots. A flexible schedule also allows them to respond to you at their convenient time while maintaining overall balance.

Create a feedback loop

Synchronization is important for both schedules. In these cases, creating a feedback loop to discuss scheduling and priorities. Encourage open communication to see what works for you as well as for others. This lets team members have mutual understanding, empathy, and respect for each other’s roles and working styles.

Time management techniques to optimize calendars

Even after balancing the schedules, developers may still not have time to complete all their tasks.

Below are a few of the time management techniques you can experiment with:

Eisenhower matrix

This technique was coined by Dwight Eisenhower. This framework is specially built for individuals in leadership positions such as engineering managers, tech leads, and heads of engineering.

This time management technique helps to prioritize tasks based on urgency and importance.

It includes four separate quadrants:

  • Important and urgent: These tasks need to be done immediately.
  • Important and not urgent: These tasks need to be scheduled soon.
  • Not important and urgent: These tasks need to be delegated or require your immediate attention
  • Not important and not urgent: These tasks need to be eliminated

Important and urgent & Important and Not urgent

Getting things done

This technique was developed by David Allen to make your tasks into a straightforward to-do list and break them down into actionable work items. It is a 5-step method that includes:

  • Capture the actions that need your attention
  • Clarify whether these tasks that have your attention are actionable or not.
  • Organize your to-do list. Prioritize them according to urgency and importance.
  • Reflect on your list of actions. Cross off tasks that are done and update your list.
  • Engage with the actions or smaller tasks that can be done right now.

Getting things done helps developers if they feel overwhelmed and struggle to focus on a single task.

Pareto analysis

This time technique is an 80/20 rule created by Vilfredo Pareto. This states that 20% of our actions are responsible for 80% of outcomes. It allows you to prioritize tasks that are most effective at solving problems.

This can be done by:

  • Note down some of the problems you are facing.
  • Identify the root cause of each problem
  • Assign a score to each problem i.e. higher number to the more important problem
  • Now, group problems together by cause.
  • Finally, add the score of each group. The one with the highest score requires immediate action.

Pomodoro technique

This time management technique was created by Francesco Cirilio. It creates a sense of urgency and focus on a single task without interruptions.

In this technique:

  • Pick up one single task and set the timer for 25 minutes.
  • After working on it for 25 minutes, take a 5-minute break.
  • Repeat this process 4 times.
  • Now, take a 15-20 minute break.

This helps to eliminate burnout and improve performance and productivity.

Pomodoro technique

The Kanban technique

Created by Taiichi Ohno, the main idea behind this visual time-tracking technique is to improve overall productivity and effectiveness. It helps to plan effectively, create SMART goals, and proper task delegation.

You have to:

  • Use any project management software, whiteboard, pen and paper, or sticky notes.
  • Determine the number of stages in your tasks and create columns.  
  • These stages can be:
    • Backlog
    • To-do
    • In progress
    • Done

There is no one-size-fits-all template for this technique. You can customize it according to your preferences and team size.


Optimizing the calendar is most important for engineering teams. They have a lot on their plate and have different working styles which allow them to create their best schedules and communicate with their team members.

Typo, an engineering management platform, allows engineering leaders to gain visibility on the team’s efficiency and workload. Book your demo and level up your developer game today!


Understanding Code Smells and How to Avoid Them

Code Smells - A common encounter by developers and testers.

They are tangible and observable evidence that something is wrong with the application's underlying code. When left unaddressed, it can degrade the application's performance and increase the technical debt. This further makes it difficult for the software teams to provide value over time and deliver the product faster to the market.

What is Code Smell?

Code Smell was first introduced by Kent Back in the 1990s and popularized by Martin Fowler’s Refactoring Book.

In simple words, code smell is a warning that the source code is messy and isn’t meeting the best practice standards.

However, Code Smell isn’t synonymous with bugs or errors. And they do not always mean that the code is wrong or broken. It highlights the presence of bottlenecks in the codebase that need immediate attention. If not, they can reduce the code quality, readability, and maintainability.

Moreover, Smelly code can easily become rotten code, when not taken care of in early stages. One of the main causes of code rot is technical debt. Hence, it is advisable to periodically check and fix them to prevent both code rot and technical debt.

Top code smells and How to Avoid Them?

Duplicate Code

Duplicated code is the most common code smell. It happens when a similar code exists in more than one area; most probably because the code was copied and pasted in different parts of the programme.

Although, it may look harmless but becomes challenging since the developer has to make multiple tweaks during feature updates. This not only decreases the code maintainability but also results in inconsistent application as the change wasn’t applied uniformly. It further increases the cycle time and is considered to be a business risk as well.


  • When there is the same method, create the same Local Variable and reuse it, and during the same class, create common Method refactoring.
  • Leverage the power of functions or loops to make code appear once in a program. 
  • Use refactoring techniques such as the Extract method, pull-up method, and substitute algorithm.  

Long Method

The long method is when the method contains too many lines of code. There isn’t any specific number of lines that are considered to be long. Some believe it to be 25 while other thinks 50 is too long.

This code smell also violates the single responsibility principle.

Long Method makes adding new features or updating existing ones challenging. It becomes harder to test, understand, and debug the code. This not only increases the cyclomatic complexity but also leads to unexpected bugs.


  • Establish maximum line counts for methods with your development team. 
  • Use the ‘Extract method’ i.e. breaking it up into several smaller methods where each of them is doing one precise thing. 
  • Remove local variables and parameters before extracting a method. 

Dead Code

The code becomes dead when the developers forget to clean up the existing code, aren’t aware of the dead code in the first place, or can be in the form of old, commented-out code. The code is no longer needed yet it is still present in the application. It can be a variable, parameter, field, method, or class.

The amount of dead code in the application signifies:

  • How well projects were managed.
  • The amount of communication between them

This makes code hard to understand, increases bugs and errors, and more security vulnerabilities.


  • Remove the dead code completely after writing the code that replaces its functionality. 
  • Use static analysis tools or IDEs such as Visual Studio as it suggests to remove the unused code. 
  • Refactor code to get rid of redundancies and maintain structure. 

Lazy Class

This code smell arises when a class exists yet doesn’t contribute seriously to the function or behavior of the software.

This increases the code complexity and clutters the code base. Hence, increasing the cognitive load for the developers which costs both time and money.

If left unaddressed for a long time, it can result in future risk i.e. Adding more functionality to the lazy class can lead to a bloated or poorly designed class.


  • Implement constant code reviews to identify and address lazy class. 
  • Determine whether the ‘Lazy class’ serves a legitimate purpose in the codebase. If not, then remove it through the remove class technique. 
  • Use the ‘Inline class technique’ to detect a lazy class and merge it with another class that uses it.

Middle Man

Middle man occurs when the class delegates work to another class and it doesn’t have any independent functionality. A few of the reasons behind this code smell are:

  • The previous refactoring may have moved functionality elsewhere and left the class empty. 
  • The middle man was relevant at one point however, it is no longer needed. 

This increases the code complexity and creates noise in the codebase. Further, it makes it harder to maintain the code and less efficient without adding significant value.


  • Document the reasons for removing the middle man to guide developers while code cleanup. 
  • Use the ‘Move method/ when the method logically belongs to another class which improves cohesion. 
  • Use the ‘Inline function’ when only a few class methods are not delegating and need to inline them into the caller. 

Primitive Obsession

Primitive obsession is a type of code smell that developers can’t identify intuitively.

It occurs when a primitive value controls the logic in a class and represents complex concepts or behaviors. In simple words, when a code relies too much on primitive values.

Using primitives for everything is certainly a bad practice. This leads to poor readability, validation, and abstraction.


  • Replace the data value with the object if the primitive fields logically belong together. 
  • ‘Introduce a parameter object’ to represent the data and clean up the code base. 
  • ‘Preserve the whole object’ when its state is needed together. Avoid extracting small parts of objects to pass around.

God Objects

God objects are one of the common and problematic code smells. It is when a single class or program is central to the system i.e. handling diverse tasks that are not cohesively related.

It violates the single responsibility principle and creates tight coupling and challenges in code maintenance.

God objects use more unwanted resources even for simple operations and make it difficult to isolate and test components effectively.


  • Refactor the class into smaller, more manageable classes. Each should hold a single responsibility.
  • Apply design patterns such as Facade, mediator, or delegation to create clearer interaction between classes. 
  • Structure code into independent, reusable modules. 

Feature Envy

This code smell arises when a class accesses the data or method of another class more than its own. It is because the class’ functionality is too closely tied to another class.

Feature envy violates the ‘Law of Demeter’ - The objects should only talk to their immediate friends, and not access their internal data and methods of other objects.

It can indicate a poor design that doesn’t include the encapsulation and cohesion of objects. It also results in high coupling between classes.


  • Look at the code and identify the class reference. Use the ‘Move method’ to consider moving relevant methods to those classes. 
  • Use the ‘Extract method’ to move the part in question if only part of a method accesses the data of another object. 
  • Apply design patterns such as strategy and visitor. 

Large Class

In this, the class contains many fields/methods/lines of code/responsibilities. This violates both the single responsibility principle and the open-closed principle.

It indicates a weakness in the design and makes it difficult for developers to understand, read, and maintain the code. Moreover, it increases the chances of errors and harder to locate them.

Note that, God objects often manifest as large classes. However, not all large classes are god objects.


  • Keep the classes small and adhere to the single responsibility principle. 
  • Use the ‘Move method’ to move a method or field to another class that is more closely related to it. 
  • Ensure thorough testing before and after code refactoring to maintain the codebase.

Improper Names

The improper names of variables, classes, and functions indicate that the code is not clean. This could happen when it includes overly abbreviated names, non-descriptive names, or using different name schemes.

This leads to an increase in the cognitive load of developers and makes them suffer from ambiguity. It also lacks precision and leads to more confusion and errors.

Besides this, improper names make pair programming and knowledge sharing challenging for the developers.


  • Keep the variable names short and descriptive and the function class should include one verb describing what they do; without adding too many words.
  • Adopt consistent naming conventions among the development team. 
  • Use code analysis tools to detect naming style violations and suggest improvements.


Unfortunately, comments are code smells too. While it is a good practice, when it is overused for every step, it creates excessive noise in code. This decreases the readability and maintainability.

The comments can be inaccurate too since the reviewer shares them based on their perspective and understanding.

The comments should only explain the ‘Why’ and ‘What it is doing’ part of the code. And not explain ‘How’ the code works. If this is the reason, it could be that the code is not self-explanatory and needs refactoring. Besides this, long, dense blocks of text can disrupt the visual flow.


  • Use the extract function to explain what a block of code does. 
  • Remove comments; rather, rely on clear and descriptive functions and variable names to convey the code’s purpose. 
  • Explore pattern techniques or libraries that can enhance code clarity without relying on comments. 

Long Parameter List

A long parameter list occurs when there is a long list of parameters in a method or class. Usually, the maximum number of parameters in a method should be 3 or 4. Otherwise, it tries to handle too many responsibilities.

It decreases the readability and reusability and makes it prone to errors and bugs. It further makes it harder to test and difficult to debug.

Besides this, It can become challenging to reuse the method in different contexts since it might require specific combinations of parameters.


  • By the ‘Introduce a parameter object’ method, create a new object from the list of parameters and transfer it as a single argument. 
  • Use ‘Preserve whole object’ when the parameters belong to a single object. 
  • Use ‘Replace parameter with method call’ when some of the arguments are just results of method calls of another object. This object can be placed in the field of its class or passed as a method parameter.

Shotgun Surgery

Shotgun surgery happens when developers have to make lots of small changes to the codebase. The code smell often overlaps with other code smells, especially duplicate code.

It might be scattered around a much larger class or may even be in multiple classes or different parts of the codebase.

This type of code smell forces a clumsy, error-free approach and unnecessarily adds complexity to the codebase. The changes consume more time and increase the cognitive load of the developers since they have to remember the changes in various places.


  • Document clearly how many files are used while making conceptually simple changes. 
  • Refactor and adhere to the single responsibility principle by handling multiple concerns into smaller, focused components. 
  • Reduce the tight coupling between classes either by applying the ‘Dependency injection’ technique or using design patterns like observer or strategy patterns. 

Inappropriate Intimacy

Inappropriate intimacy occurs when a method has too much intimate knowledge of another class or method’s inner workings or data. It means bi-directional behavior between classes that are tightly linked to each other.

Changes in one module can easily break the other due to their deeply intertwined nature. This results in difficulty in enhancing/extending features and bug fixes.

Inappropriate intimacy also reduces modularity, flexibility, and testability.


  • Use the ‘Encapsulate field’ when inner data needs to be exposed instead of being private. 
  • Use the ‘Extract interface technique’ to define a common interface for the classes that need to interact with each other. 
  • When two classes are too related yet don’t talk much to each other, they need a split, merge, or refactor. 

Typo - Automated Code Review Tool

A code smell is a common problem faced by developers, indicating the potential issues within a codebase. It is important to address them in the early stages, otherwise, it can reduce the code quality and slow down the entire development process.

Detect these code smells with Typo’s automated code tool which enables developers to catch issues related to maintainability, readability, and potential bugs. It identifies issues in the code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps the code error-free, making the whole process faster and smoother.

Key features:

  • Supports top 8 languages including C++ and C#
  • Understands the context of the code and fixes issues accurately
  • Optimizes code efficiently
  • Standardizes code and reduces the risk of a security breach
  • Provides automated debugging with detailed explanations

How to give code review feedback?

Code review helps you to improve the quality and maintainability of your code. However, this process is challenging for both engineering managers and developers. While managers need to perform thorough reviews to ensure code quality, developers are usually overwhelmed when receiving feedback.

Engineering managers need to be courteous and respectful while offering constructive feedback to their developers. They must be clear with their feedback so that developers can understand your feedback in the right way and not take it negatively.

In this blog post, let’s explore the ways to provide code review feedback to developers:

What is Code Review?

Also known as peer review, code review is a key practice within quality assurance. It is a systematic examination of a software code by one or more individuals to improve its quality, identify issues, and ensure that it aligns with established coding standards and best practices.

Why Code Reviews are Important?

Catches Issues Early

Code reviews allow engineering managers and developers to detect issues and bugs in the early stages. So that the problems can be fixed before the end-users see them. Besides this, It allows developers to work with fresh knowledge, or else they may struggle to remember code, solutions, and reasoning.

Supports Knowledge Sharing

Reviewing code regularly allows developers to learn more reliable techniques and best practices. It helps in gaining valuable insights into diverse coding styles and problem-solving approaches. Code review also allows engineering managers to mentor junior developers and foster a culture of continuous learning and growth.

Increases Code Readability

Regular code reviews ensure the entire team adheres to consistent coding standards and best practices. This makes it easier for developers to understand and contribute to the codebase. Hence, they can write more readable and maintainable code over time. Besides this, it provides opportunities for refactoring.

Minimizes Technical Debt

Optimizing code through the code review process eliminates a significant amount of technical debt. It also detects code smells which are early signs of potential technical debt. Code reviews analyze the code and catch bugs to reduce the need for extensive rework later.

Crafting Better Code Reviews. Adapted and reworked from a talk… | by  Vaidehi Joshi | Medium

10 Ways to Provide Code Review Feedback

Ask Questions During the Code Review Process

Always ask questions rather than demanding changes. It not only opens up a dialogue but also lets them think about input without being defensive. This also ensures that both parties can decide on the right course of action and know each other's perspective. When asking questions, developers can explain their thought process and rationale behind the code. This also fosters a culture of collaboration and highlights that nobody is always right.


Instead of saying ‘Change the variable name’, ask ‘I see you named this variable ‘Temp’. What about calling this variable ‘UserID’?

Avoid Using Condescending Words

It is seen that written constructive feedback is usually taken negatively. Since the individual cannot see the body language, facial expressions, or tone of the other person. Words like just, easy, and obvious may seem belittling to the developers. This not only diminishes confidence but also introduces ambiguity within the team.

Make sure that you provide feedback in clear and complete language. And most importantly, Be polite!

This will help developers grow and work efficiently. Hence, enhancing overall code quality.


Don’t say ‘This fix is way too easy’. Instead, use this ‘I see a straightforward implementation here. Can you walk me through your decision-making process?’

Focus on the Code, Not the Developer

Address the code directly rather than the developer. Discuss what can be improved in the code, not the developer’s skills or characters. Blaming them will lead to judgments, rejections, and defensiveness. They would avoid taking feedback positively.

Hence, ensure an objective evaluation of the code. Make this process a team sport and focus only on facts.

This will not affect any interpersonal relationships within the team and developers will take feedback seriously.


Instead of saying ‘You haven’t optimized the code efficiently’, You can say ‘This code hasn’t been optimized properly’.

Explain the ‘Why’ Behind the Feedback

Instead of just telling what improvements to be made to pull requests or code, explain the reason behind the change. Let developers know about the thought process and reasoning so that they look from the other’s perspective. Add a brief explanation along with the change mentioned.

Never assume that developers understand the ‘Why’ behind the change. Always clarify the reason so that they know where it is coming from.

This will help developers improve their skills and knowledge, enhancing code quality.


Don’t say ‘Update the variable names’. Instead, say this ‘Try adding descriptive variable names to enhance code readability and make it easy for other developers to collaborate and maintain the codebase.’

Use ‘I’ Statements

Clarify to developers that it is not a universal statement or generalization. Rather, it’s an observation or one perspective as per the code written.

Hence, use ‘I’ while writing constructive feedback. It not only fosters an open and receptive environment for discussing code changes and improvements but also makes it easier for both sides to look for solutions.

This makes developers less defensive about their work and more open to pair programming and learning opportunities.


‘The code is hard to follow’ should be changed to ‘I am finding this flow of code a bit challenging to follow.’

Suggest Solutions

Always suggest solutions and guidance on how they can improve. It could be a framework, method, or API. It doesn’t mean giving a complete solution but sharing an improvement strategy. This will save developers time in implementing these suggestions and address issues (which they might have overlooked). Also, they will be able to learn new techniques, best practices, and coding standards to improve their coding skills.

Use examples as well so they understand the solution practically.


If the loop structure is inefficient, suggest a solution like ‘Consider using a 'for-each' loop instead of a 'for' loop for better readability and concise code.’

Share Learning Resources

Apart from solutions, share learning resources with them. It could be related to the areas where developers need improvement, new industry trends, or code review best practices. It will help them stay updated with the current trends and improve their understanding of specific technologies and frameworks. Resources such as relevant documentation, tutorials, and online courses work wonders.

This will help developers take ownership of their learning and foster a sense of autonomy.


Instead of simply pointing out the developer’s blindspot, for example - Not familiar with the new framework’s syntax. Write this - ‘I noticed some challenges with the syntax of the new framework. I recommend checking this document ‘Framework Documentation.’ as it provides clear examples and explanations.’

Keep Code Reviews Small

Review code frequently as it reduces the need to make the process lengthy. Long code reviews would be overwhelming and confusing for developers since they need to make a lot of changes and improvements altogether. Even after doing it frequently, the code reviews take hours, break it down into small parts.

Smaller code reviews allow developers to understand the reason behind the constructive feedback. Hence, they can make changes to the code without any dilemma or misunderstanding.


Suppose a developer has submitted a large pull request that considers various features and changes.

Instead of sharing feedback all at once, say this ‘Let’s first focus on the changes related to the new feature implementation. Once done, we can move on to reviewing the improvements in the existing code.’

Appreciate your Developers

Effective code reviews take place when both positive and constructive feedback is included. Developers may make a few mistakes here and there. But, this doesn’t come from a bad place. They are improving, growing, and giving their best.

Hence, pat their backs on the things they have done correctly. Positive feedback creates a culture of recognition and gratitude which improves collaboration and communication.

This also lets development teams to continue put efforts and strive for excellence.


When recognizing their efforts, say this ‘Nice job on the new feature. Your attention to detail and writing readable code is commendable.’

Use Automated Code Review Tools

Use code review tools to help in assessing the quality of code. These tools can help in spotting bugs and vulnerabilities, detecting code smells, syntax errors, security vulnerabilities, and many more. It also gives visibility into changes, hence, making the feedback more focused and contextually relevant.

These tools also ensure that the code adheres to the coding standards and best practices.

Typo: Automated Code Review Tool

Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.

Key Features:

  • Supports top 8 languages including C++ and C#
  • Understands the context of the code and fixes issues accurately
  • Optimizes code efficiently
  • Provides automated debugging with detailed explanations
  • Standardizes code and reduces the risk of a security breach


The code review process might be time-consuming, but, it is rewarding too. It helps in knowing whether the code needs refactoring, has bugs or errors, or anything else that could hamper its performance.

Follow the 10 tips mentioned above to encourage collaboration, open communication, and knowledge sharing among developers.

Happy reviewing!

How to Choose Between Product Management & Software Engineering?

Product Management and Software Engineering are among the roles that drive innovation for a product. And today, these roles are intertwined in ways that responsibilities and capabilities can seem blurred – which leads to the question, which role is right for you?

Product Managers answer the “why” and “what” questions about a product, while the Software Engineers answer the “how” – both important in software creation.

Choosing between product management and Software Engineering can be challenging since they are crucial for businesses. To help you make an easy decision, in this blog, we break down their roles, career responsibilities, trajectories, differences in day-to-day work, and where they are similar. Let’s dive in!

The Role of a Software Engineer

The Product Managers serve as the guiding strategic navigators of innovation and steer products from a mere idea, conceptualize it, and take it all the way to market launch. They provide the blueprint for the product’s path from inception.

Unlike Software Engineers, the Product Manager role extends beyond coding. They combine business acumen, technological insights, and customer-centric thinking and translate into the fulfillment of a product.

They deep dive into market analysis and identify user needs, effectively shaping the product roadmap. With this information, Product Managers align customers with business objectives. The product role also includes fostering a collaborative culture between engineers, designers, sales, and marketing teams while staying true to ever-changing market dynamics through agile methodologies.

They drive teams toward a shared goal while crafting a roadmap.

The Role of a Product Manager

The Product Managers serve as the guiding strategic navigators of innovation and steer products from a mere idea, conceptualize it, and take it all the way to market launch. They provide the blueprint for the product’s path from inception.Unlike Software Engineers, the Product Manager role extends beyond coding. They combine business acumen, technological insights, and customer-centric thinking and translate into the fulfillment of a product.They deep dive into market analysis and identify user needs, effectively shaping the product roadmap. With this information, Product Managers align customers with business objectives. The product role also includes fostering a collaborative culture between engineers, designers, sales, and marketing teams while staying true to ever-changing market dynamics through agile methodologies.

They drive teams toward a shared goal while crafting a roadmap.

The Career Paths of Software Engineers and Product Managers

A Software Engineer’s Journey

A Software Engineer evolves from an entry-level position to senior and staff levels. This path can lead them to management roles. They can manage engineering teams and progress to positions like VP of Engineering, CTO, and Director.

However, through this transition, they must develop varied skills to support their growth. From purely technical skills, their role can evolve to people management, a distinct skill honed over time.

A Product Manager’s Journey

Product Managers also grow similarly in their career paths. They move from being individual contributors to leading fellow Product Managers. It often involves market research and product marketing. Their trajectory then moves into the business aspects of the organization. Many of them move into roles like Managing Directors or Vice Presidents. In such roles, they oversee several divisions and business lines.

In these roles, Product Managers influence the product strategy and the marketing, sales, and finance functions in line with the company’s goals.

Understanding the Nuances of these Roles Entails Delving into their Day-to-Day Responsibilities

To know which role is right for you, understand what the day-to-day responsibilities of the roles look like:

A Software Engineer’s Responsibilities

  • Designing comprehensive solutions for complex technical problems
  • Writing, debugging, and optimizing code for software functionality
  • Collaborating with fellow engineers on coding projects and sharing best practices
  • Integrating and testing software components for seamless functionality
  • Providing maintenance, support, and enhancements for existing systems
  • Investigating and troubleshooting software issues promptly
  • Participating in code reviews to enhance code quality and identify potential issues
  • Contributing to the development of engineering processes and best practices
  • Mentoring junior engineers through code reviews and design discussions
  • Designing and development of software architecture
  • Have problem-solving ability to identify and analyze technical challenges

A Product Manager’s Responsibilities

  • Conducting thorough market research to assess competition, user needs, and trends
  • Collaborating with cross-functional teams: engineering, design, sales, and marketing
  • Identifying customer needs and translating them into actionable product features
  • Developing compelling business cases for new ideas and improvements
  • Crafting comprehensive product roadmaps aligned with business objectives
  • Prioritizing and managing requirements from stakeholders and customers
  • Making informed decisions on feature trade-offs during development
  • Addressing the launch process and measuring success through user feedback
  • Building and maintaining relationships with partners and stakeholders
  • Communicating product vision and strategy to internal teams and stakeholders
  • Comparing Product Management and Software Engineering Roles: A Comprehensive Analysis
  • Staying updated on market trends and emerging technologies
  • Creating product marketing strategies to promote the product to the target audience

An Analysis of the Difference between Product Managers and Software Engineers

Software Engineers and Product Managers drive the creation and evolution of software products. However, each has a distinct set of responsibilities, strategies, and perspectives. A project needs a blend of these roles and their unique skill sets.

Nature of Work

When working as a software developer, it's important to acknowledge and appreciate each team member's unique roles and responsibilities. Even though everyone has specific tasks, teamwork is still crucial to success. That's where a Product Manager comes in - as a mediator between stakeholders and the engineering team, they gather feedback and ensure everyone is on the same page.

While the PM might help push specific deliverables, it's ultimately up to the engineering team to execute them. That being said, the PM might be held accountable for the project's overall outcome, especially regarding user satisfaction and management expectations. It's crucial to understand the difference between responsibility and accountability in any project and to work together to achieve success.

Technical Gaps vs. Product Gaps

Software Engineers and Product Managers have contrasting approaches to tackling gaps in products. While engineers focus on technical obstacles and evaluating technologies, Product Managers prioritize bridging gaps and identifying opportunities. They streamline user scenarios, engage with users, and ensure alignment with key stakeholders. Collaboration between the two roles leads to impressive outcomes, with PMs providing valuable input and engineers making technical trade-offs to create optimized features.


It is essential to recognize that different roles in product management have varying timeframes. Software Engineers (SWEs) typically operate on regular sprints, often on a weekly or bi-weekly basis, which enables them to structure their working schedules and remain on top of their tasks. In contrast, Product Managers (PMs) have more flexible timelines, as their responsibility lies in steering long-term strategies.

While PMs must pay attention to immediate tasks and customer feedback, they must also align with engineering sprints to provide the necessary specifications and artifacts. To be a good PM, it is essential to support the engineering team, and engineering timelines should influence their timeline but not necessarily be linked to them.


As a Software Engineer, it can be challenging to keep up with the frequent deliverables that come your way. From minor bug fixes to complex feature releases, each deliverable can impact the user differently. Some tasks, like maintenance tasks, may seem insignificant, while others can be game-changing for the product.

When it comes to customer-facing products, the release cadence may be less frequent, but the user impact of each new feature or improvement can be significant. It's essential to consider the user's perspective when prioritizing and planning deliverables to ensure a positive experience.

Scope and Ownership

Software Engineers typically have a one-month ramp-up period before their responsibilities increase. At the same time, project managers may require up to two years, especially in larger companies. This is due to the complex decision-making involved in project management and the need for a deep understanding of the context. Although Software Engineers and project managers can impact user experiences, project managers are generally responsible for end-to-end user scenarios.

Navigating your Career Path - Do you Want to be a Software Engineer or a Product Manager?

Let's simplify each role to help you decide which suits you best.

Exploring Product Management

Do you enjoy strategizing, collaborating, and connecting user needs with product plans? If so, Product Management might be your fit. As a Product Manager, you'll shape the "what" and "why" of a product, drawing insights from user research. You'll understand customer desires, align business goals, and guide teams, from concept to product launch. If you love crafting solutions and teamwork, this could be your calling.

Understanding Software Engineering

Are you intrigued by coding, solving problems, and building software solutions in a technical role? Software Engineering might be your compass. Software Engineers craft the "how" of products by turning ideas into functional code through their expertise in software development. If you thrive on coding challenges, value technical expertise, and want to create digital innovations, this path could be for you.

Making your Decision

Remember, these paths often blend, and you're in control. Consider your strengths. Do you want to explore code and technology? Software Engineering might be your choice. Or do strategic thinking and teamwork drive you? Product Management could resonate.

Both roles demand learning and adaptability, shaping our tech world. As you gain clarity, let your choice align with your ambitions, guiding you toward a fulfilling career in the ever-changing tech landscape.

Choose the career path that resonates with you

If you are passionate about technology, product management, and engineering are fascinating fields. They provide unique paths to explore, each with its challenges and rewards.

Whether you thrive on navigating the strategic landscape of product development or find joy in the creative process of coding, your choice of focus reflects your aspirations and strengths. By embracing the path that resonates with you the most, you can build a fulfilling and impactful career in this exciting industry.


Code rot: Signs and Ways to Address it

Code rot is a common problem among engineering teams. It can compound unless it is well-managed.

Just like how we need to nurture our plants to grow or else they will be withered. The same should be done with code, otherwise, it will rot.

So, let’s delve deeper into the concept of Code rot, ways to recognize it, and how to address it.

Code Rot: Definition

Also known as software rot or software decay, It refers to the deterioration in the performance of a piece of code. It doesn't mean code doesn't break down or rot away. Rather, the quality of the code starts degrading over time, emphasizing the importance of clean code practices.

This further makes the software faulty, unusable, or need upgradation. If not taken care of in the long run, it can also directly impact the team’s productivity and morale.  

2 Types of Code Rot

Active Code Rot

Active rot shows signs of code while they are actively handled and maintained. Also known as Gradual Decay, these codes slowly worsen in small details. The common type of code rot can be found in every code base to a varying degree. This is because most software requires constant updates and bug fixing. Hence, deviating the program from its original design.

Dormant Code Rot

Dormant rot is easy to detect. This code isn’t being touched constantly which makes them useless as the rest of the application upgrades. The reasons could vary. A few of them include API no longer working, Hardware and platforms have stopped working, and missing device adaptations.


Recognizing Code Rot

Code is Fragile

In this case, the code breaks in many places whenever a change is made. The code isn’t stable as software becomes difficult to maintain. When the code is fragile, every new change introduces several new defects. Even when the areas aren’t related to each other. They can be either detected early by an automated testing suite or found in production by end-users.

Software Metrics are Declining

Declining software metrics don't always indicate code rot, but they can be a warning sign that the code needs to be reviewed. Sometimes, it's a slow deterioration, showing that the code isn't as healthy as it once was, and action should be taken to resolve it. A few of the metrics that can collect software codebase health data include Coupling, Cyclomatic Complexity, and Test Coverage. These metrics provide valuable insights into software complexity and can guide improvements.

Code is Rigid

When the code is hard to change, it can be a warning sign of code rot. Even when it is a simple change, it takes longer than expected. Moreover, one change may lead to other changes as well. The code becomes less adaptable to changes and prone to errors, instability, and crashes. As a result, this leads to a slowing down of the development process.

Increase in Time to Deliver Value

In continuation of the above point, code rigidity can also increase the time to deliver value. As the code is in an unhealthy state, more time will be needed to add new features. Hence, it takes longer to ship new features to the customers. Moreover, the developers may fear managing non-critical issues as they aren’t sure of the full impact of the change.

Documentation is Outdated

When the documentation isn’t updated or maintained for a long time, it gets out of sync with the code. This makes it misleading. As a result, it creates confusion and errors for developers to rely on it. If the documentation remains outdated for a long time, it can make the end users unhappy with the product.

Addressing Code Rot

Create Standardized Coding Guidelines

You can start by defining what Healthy software stands for in your organization. Establish a set of common coding guidelines and practices for your team members. It allows them to be on the same page and move in the same direction. Moreover, it creates a social contract between the team and lets them consistently write code.

Use Software Metrics

Software metrics may not necessarily identify code rot. But it can help in knowing the quality and health of the codebase. Various metrics such as cycle time, code churn, and cyclomatic complexity let the developers know how the code is performing. It can identify code smells and technical debt, track their changes over time, and much more. Hence, helping in further inspection.

Refactor Often

Software metrics can also help in knowing the blind spots within your software development. Hence, it helps developers to know which areas need refactoring to enhance the overall quality of the code. Refactoring them in small, frequent iterations lets the code adapt better to new environments and improves its quality and longevity. This approach also assists in the gradual improvement of the code base and keeps it manageable, ensuring that your test suite remains effective.


While manual testing may take a lot of time, you can go for automated testing of the code. However, ensure that the code is written with testing in mind. It lets you know whether the code is working as expected. Moreover, if any recent changes are made, automated testing lets the developers know any previously working functionality has been affected. Hence, helping in detecting the issues early.

Mentor New Developers

Lastly, after hiring the right set of developers, ensure that you train them regarding coding guidelines. Make them understand how refactoring should be done often and coding best practices. Try aligning them with other developers. Create a culture of continuous learning and foster open communication in your organization.


While code rot is a universal problem, It can still be prevented. Take care of your code base often. If any issue is detected, take the necessary steps at the earliest.

Typo, an intelligent engineering platform, can help in identifying SDLC metrics. It can further help in detecting blind spots and reducing code rot.

Scrum Velocity - How to Use it the Right Way

Speed is crucial in software development, but it’s not the only thing that counts. Without clear direction and purpose, your team may struggle to stay on track and deliver valuable results. This is where scrum velocity can help you.

So, let’s delve into the concept of Scrum velocity, how it’s calculated, and why it’s a game-changer for Agile teams.

What is Scrum Velocity?

Velocity is speed with direction, and development speed without direction is an utter waste of time. Therefore, team velocity in scrum development is the team’s capacity for producing useful, working software. Simply put, scrum velocity is one of the key agile metrics that represents the capacity of a development team to achieve a given purpose.

For example, if a team completes user stories with a total of 30 story points within a two-week sprint, their velocity for that sprint is 30.

Calculation of Velocity: Story Points Completed Per Iteration

To calculate velocity in Scrum, follow these key steps. First, determine the unit of measurement to track progress and select a time frame (iteration or sprint) for the calculation. Once these basics are in place, track completed story points.

Story points are used in Scrum to estimate the size or complexity of user stories or backlog items. Teams can compare and prioritize different pieces of work based on their difficulty level.

Track progress during the sprint by recording the total number of story points completed. This allows accurate calculation of velocity at the end of the sprint.

Velocity is measured per sprint and used for planning and productivity measurement. Tracking velocity, a fundamental Scrum metric, helps forecast how much work can be accomplished in future sprints and informs release and iteration planning. If there is a user story with 4 story points and another with 5 story points, then this sprint’s scrum velocity is 9 (4+5) by adding both story points.

Benefits of Velocity Tracking

Velocity tracking is one of the key agile metrics used in Scrum and other agile frameworks. Below are a few benefits of velocity tracking:

Helps with Planning

Monitoring velocity is essential for boosting team productivity and improving forecasting and planning. By tracking velocity across various sprints, the team can establish a standard and use it to estimate the amount of work they can handle in future sprints. This ensures that they can set practical goals and make informed commitments to stakeholders.

Improve with Each Iteration

By using velocity tracking, the team can detect patterns and trends in their performance. They can also examine the factors that cause fluctuations in velocity, such as changes in team structure, task complexity, or external dependencies. Through iterative development, the team incorporates lessons learned from each sprint into the next, fostering a cycle of continuous improvement. By better understanding these factors, the team can refine and improve their procedures, resulting in more dependable and consistent delivery.

Fosters Better Collaborative Team Spirit

When teams can track their velocity and see improvements or consistency, it significantly impacts their motivation and overall satisfaction with their job. This can also foster a spirit of collaboration and transparency within the team as they work together to achieve their goals and continuously improve their velocity.

Enables Transparency

Monitoring velocity provides an exact measure for stakeholders and management to track team progress, capacity, and abilities. It encourages transparency and fosters trust between the team and stakeholders, leading to successful collaboration.

Limitations of Scrum Velocity

Velocity Targets can be Counterproductive

While velocity is a valuable metric for scrum teams, setting it as a target can create undue pressure and even lead to punishment for team members who fall short. A more compassionate approach focuses on tracking metrics and identifying any underlying causes of issues. This way, your team can improve their processes, eliminate bottlenecks, and incorporate new tools to enhance their skills over time.

Leads to Team Comparison

It’s understandable that teams approach projects in their unique way, so it’s not always fair or practical to judge them solely based on their speed. A team’s velocity can be influenced by various factors, including the project’s complexity and the team members’ individual skill sets.When calculating scrum velocity, it’s important to remember that story point estimates can be subjective. Comparing teams solely based on velocity can lead to a negative work environment, internal conflicts, and low morale. It’s better to use this measure to navigate situations within a team rather than to compare teams against each other.

When you introduce the concept to the team, it’s understandable that every team needs time to work together effectively. Whether they’re a new or old scrum team, they would take time to understand new complexities and create action plans. It’s unrealistic to expect them to perform at maximum velocity right away, and it’s common for leaders to have unrealistic expectations based on an outsider’s perspective. Only the scrum teams and managers working on the project can accurately estimate true scrum velocity, as they’re facing internal roadblocks and several complexities.Therefore, providing them with space and time to work together effectively is crucial. Business leaders who fail to acknowledge this may unknowingly hinder their team’s progress and prevent them from moving in the right direction.

Lack of Consideration for Unplanned Activities Affecting Quality

Scrum teams must allocate time for unforeseen activities, such as addressing technical debt and critical bugs reported by customers. But teams who only focus on scrum velocity need more investment in quality.

Neglecting these essential tasks can lead to a decrease in the quality of the final product and cause issues for future timelines. Short-term focus on velocity can hurt progress and ultimately harm business success. Therefore, it’s crucial to invest in the necessary resources for scrum teams to work effectively and prioritize quality over speed.

Using it to Determine Completion Estimations

While some team leaders rely on scrum velocity for project completion estimates, this may not align with Agile principles. Factors such as changing requirements, short development sprints, and unpredictable variables affect velocity.

Therefore, depending solely on a static tool or metric for progress measurement may not be an efficient choice, especially if it only provides an estimation instead of a precise timeline. It’s important to remember that scrum velocity can only offer an approximate timeframe for project execution and should be treated as such.

Using it as a Performance Metric

Overemphasizing scrum velocity as a performance metric can lead to inaccurate predictions and frustration when tasks take longer than expected.

Moreover, assigning blame for incomplete stories can create negative feelings among team members. To avoid these issues, remember that velocity should only be used for prediction purposes and not for comparison or competition. Ultimately, the goal of development should be predictable progress rather than constantly increasing speed.

Lacks Details

While velocity provides a general sense of how much work has been completed, it doesn’t give the full picture. You must account for factors like technical debt, bug fixes, and non-functional requirements to ensure you get all the important details that impact the overall value the team delivers. It’s essential to look beyond the surface level and consider the specifics of what was achieved and the quality of the work.

Tips to Improve the Use of Scrum Velocity

As part of sprint planning, the Scrum Master plays a crucial role in facilitating these retrospectives and ensuring that the team's feedback is incorporated into future sprints.

  • Use reference stories, comparative sizing, or historical data to improve story point estimations.
  • Regularly conduct retrospectives to reflect on team performance and improvement by discussing challenges. This fosters a collaborative environment and celebrates learning.
  • Improve our productivity through experimentation with various Agile practices, techniques, and tools. Regularly seek reviews and refine Scrum processes based on feedback. 
  • Optimize productivity during each sprint by limiting the work in progress and overburdening the team with multiple user stories. Prioritize completing a smaller number of high-quality user stories. 
  • Don’t fixate on velocity numbers; instead, track trends. Identify patterns for better forecasting and planning.
  • When evaluating a team’s performance and productivity, it’s important to consider more than just velocity. Other metrics, such as cycle time, lead time, and cumulative flow diagrams, can provide valuable insights and help create a complete picture of the team’s progress. 

Use Scrum Velocity to Enhance Your Productivity and Not Limit it

As an Agile team, it’s essential to recognize the significant role that velocity plays in your success. By understanding your team’s past velocity, you can better plan for future sprints and set realistic goals everyone can commit to within the Scrum framework. This helps keep everyone on the same page and provides a clear measure of your productivity and progress over time.

It also enables you to make data-driven decisions and aim for constant improvement. Ensure you look at scrum velocity objectively and not as a sole indicator of performance and productivity.

By following some simple tweaks to your process and journey with scrum velocity, you can achieve your goals efficiently.


How to Prevent High Code Churn?

Developers are constantly juggling between one or the other tasks. It may seem a ‘normal’ thing, but it can harm the software development process. If not measured timely and properly.

There are many metrics that engineering managers can take note of. But, here we will be discussing one of the important yet overlooked metrics in software development – Code Churn.

In this blog, let’s dive deeper into code churn, what causes high code churn, and how you can prevent it:

What is Code Churn?

Also known as code rework. It is when a developer makes changes to a specific piece of code including a file, a class, or a function during the development process. Although, it is a normal thing, but also depends on when and why it is taking place.By this, we mean that testing, reworking, and exploring various solutions to a problem is fine. Especially, during the beginning of the project when code doesn’t have a clear solution.

It is healthy and expected unless it surpasses 20% – This is when it is a problem. The lower the code churn, the closer you get to a release date.

What Causes High Code Churn?

How to Prevent Customer Churn With Machine Learning | by Richie Frost | The  Startup | Medium

Common workflows and dynamics that can result in a high churn rate include:


Prototyping is a natural and healthy trend. It is usually seen when there is a new or unfamiliar project. During these times, the churn rate may rise to 60-80% and this is not unusual.

Apart from prototyping, redesign, and POCs are all examples of where large chunks of code are rewritten. Hence, it is fine to allow developers the time and space to research and experiment.

But, if it continues for an extended period beyond what was expected then it is a cause for concern. It could be that the developer is not able to comprehend the specific components or the entire problem. Or the problem could be complex.

Unclear Software Requirements

One of the main factors behind high churn rates is inconsistent or unclear requirements. It further spreads to subsequent phases of software development which compromises the quality of final products.

It could also be that the requirements change midway through the work which is another reason for high code churn. Due to this, developers may rely on their best guess to interpret and fill in any gaps. As a result, some assumptions could be wrong too.

This further damages the morale and progress of the development team.

Uncertain Developers

Uncertain developers may also impact team performance as they juggle between various approaches, such as:

  • Figuring out the best way for the task
  • Lacking the needed skill 
  • Struggling to make firm decisions about their project direction 

Any of the above leads to subsequent changes in the code base which results in a delay in progress. Since decisions are constantly revisited or revised.

Complicated Tasks

Complex tasks are another reason for higher code churn. Since the developers are continuously exploring and backtracking the project, it is not unusual that churn rates may exceed the desired level.

But, as mentioned above, if it goes on for too long, then it is a cause for concern. It could be that developers may not have the resources they need or may require additional help.

It can also increase Technical Debt resulting in high code churn. Developers take shortcuts and make compromises that hinder the entire development process.

Burnout and Turnover

Software developers are more likely to be burnout due to their busy work schedules. Even when enough resources are available and they have the required skills, developers who are burnout may not be able to do their tasks efficiently.

It can further result in becoming disinterested in work, failing to show up, and increasing the rate of presenteeism. Hence, developers may want to change their jobs resulting in an increased turnover rate.

When former developers resign, new ones replace them. They would need time to familiarise themselves with the existing code and team. Hence, it leads to knowledge loss which causes potential errors or inefficient changes.

Why Measuring Code Churn is Important?

Minimizing and managing code churn is done by measuring it. This allows you to prepare to take things in control when there is an increase in code churn.

Measuring it helps you understand the software development process and know how many times code is changed. It also lets you see in-depth insights into internal and external hurdles allowing you to create actionable plans.

5 code Churn Metrics are:

Code Churn Count

It is the measure of the number of times the developers made changes to the file in GIT control.

Lines Added

The number of lines of code that were added to files for the code that was written recently.

Lines Deleted

The measure of lines of code that was deleted from files within three weeks of writing the code.

Lines Modified

The measure of lines of code that was modified within three weeks of writing the code.

Total Code Churn

The total of lines added, lines deleted and lines modified.

How to Reduce High Code Churn?

Define Clear Project Requirements

High code churn usually arises when requirements are not properly defined. Hence, it is important to take sufficient time to understand the requirements.

In case, the requirements are ambiguous, ask for additional clarification and review it once before starting with the project. Make sure that every team member is on the same page and knows what needs to be done.

Also, aware clients and stakeholders as well of how mid-stream changes can result in slow delivery and increased time.

Effective Planning

Higher code churn usually occurs due to ineffective planning. Always use data-driven and factual insights to plan team and task allocation for reducing code churn. It includes thorough pre-development preparation, comprehensive requirement analysis, and careful project scheduling. This reduces the likelihood of frequent code changes or major rework during later stages.

Moreover, effective planning allows software engineering teams to navigate new areas of the codebase.

Address the Root Cause

Understanding the root cause lets you identify a long-term solution that helps in improving the quality of the database.

For example, if you are aware that the developers are still lacking needed skills, you can involve pair programming sessions with senior engineers.

Failing to address the root cause makes you constantly make changes to the codebase which lets you create a cycle of rework and inefficiency, potentially leading to bug fixes and future quality problems.

Coding Standards and Style Guides

Usually, developers spend more time reading code than writing it. Hence, ensure that the code is readable to all.

It could be that developers may have different professional qualifications and work experience. Their language preference and writing styles could be different from each other. Hence, implement standardization in the workplace. And ensure that your team knows about it.

Also, select coding style guides. It will allow developers to read code easier and faster. It further helps in promoting best practices and coding techniques, leading to low code churn.

Code Reviews

The code review process lets developers catch errors early in the development process. This further helps in improving code quality.

Apart from this, code reviews also allow team members to identify areas where code needs refactoring. As a result, helping them to prevent the need for extensive rework later. Code reviews let developers get honest feedback at the right time.

Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.


High churn can signify that developers are innovative and determined. But, when it goes on for a long period, there is a problem that needs to be addressed as soon as possible.


How to revert a Git Pull Request?

Pull requests are made on git to work with a team collaboratively. In most open source projects, the contributors request for the review and acceptance of a branch, and then depending on the vitality of the code, it is either accepted into the code or not.

However, what happens when it is not merged and needs to be reverted? This is why we’ll tell you how to revert a git pull request.

Why is a Git pull request needed?

You want to avoid being in a position of reverting the pull request as often as possible, but sometimes, you just have to do it. And a lot of situations are beyond your control. So here are some of the reasons:

  • The pull request was accepted and merged by mistake. This ends up with the original code having a bunch of broken code. 
  • The commits made to a branch consist of unintended changes.
  • The commit adds issues to the code affecting the functionality of the codebase.
  • A conflict occurs with a different change in the codebase, so you need to revert until a solution is found.
  • A new feature change was intended to be experimental but caused issues to the stability of the codebase.
  • The pull request was associated with a different branch, which can happen when there is a complex branch strategy 

How to revert a Git pull request?

There are multiple ways you can revert a git pull request; some are safer than others. Here are some of the methods:

Creating a pull request for the revert 

Whenever a revert is made, it creates one revert of the merge commit.

If you have write permissions, go ahead with the following steps:

  • Click on pull requests in your repository.

pull requests in your repository
  • Select the pull request you want to revert.
  • Click on the revert option that you see at the right bottom.
revert option
  • If you don’t have write permission, request your administrator for it.

Reverse using the git revert command

The Git revert command helps you create an inverse to the introduced changes and adds a new commit with these changes.

Here are the steps:

  • Open your terminal and navigate to the repository where you want to revert the pull request.
  • Use git log to show the commit history and find the ID of the commit you want to revert.
  • Input the commit ID and execute the git revert command.
  • Provide a detailed Git commit message to clarify the reason for performing the Git revert.

This step doesn’t remove the changes made but adds changes to negate the pull request.

Reverse using git reset

The previous method altered the new reality caused by the merged unneeded pull request, but Git reset is like going back in time to change what was done.

While this might have unintended consequences, it might still be a route you can take if needed, and here is how you can do it.

  • Find the commit hash that you want to revert to using the git log.
  • Use git reset with the --hard flag and the commit hash to reset the branch to that commit—for example, git reset --hard abc123.
  • Force-push the changes to the remote branch using git push -f.

Undo your pull requests but be smart about it

Pull requests are an integral part of working collaboratively, and merging them by mistake or without enough review can cause many issues to the codebase. Then reverting this process can have other consequences you want to avoid. Therefore, have an internal process to merge pull requests. Ensure everybody is on board with the code reviews needed for the process and a checklist to denote when a merge is acceptable.

We at Typo can help you improve your engineering processes and deploy quality code faster. You can quickly get started with our tool on Git for a seamless experience.


How to Count Lines of Code: A complete Overview

Counting lines of code can be used as one of the metrics to assess your developers' productivity and the efficiency of code bases. Therefore, in this blog, we dive into the different methods to count lines of code and what we think about this metric.Let’s dive in!

Methods to count lines of code

There are several ways to count LOC, some more efficient than others with different objectives. So we have a list for you to use the best method that suits your needs.

Manual Counting

Counting lines of code manually involves going through each line of code and tallying the lines while excluding comments, blank spaces, and non-executable lines.To do this, open the source code file and count the lines with a paper or text editor. Go through it line by line and check for executable code.Once you are done, note the total count.However this method might sound simple, yet it is tedious and prone to errors. Automated tools are more accurate and efficient, and we will discuss them in the following methods.

Count Lines of Code Command 

The Count Lines of Code (CLOC) command is a tool that automates counting lines of code.Here's how to use the CLOC command:

  • Open the terminal or command prompt and navigate to the code directory. You can use the command ‘cd’ followed by the path to reach it. 
  • Run the CLOC command: cloc <directory> (replace <directory> with the path to the code).
  • If you want to count the lines of the entire directory, simply replace the directory with a dot ‘.’ 
  • Wait for the results, which will include the total lines, blank lines, comment lines, and lines of code for different programming languages.

Here is an example of the tool and its results.

example of the tool and its results

The automated categorization of lines into different types and comprehensive statistics using CLOC makes it superior to manual counting. You can trust the reliability and efficiency of this tool to save you a lot of time and effort.

Use statements to count lines of code 

While the above methods show the lines of code, if your code increases in more blanks, comments, and statements, then the number gets inflated without any value added to the functionality.Therefore, statements count is much more helpful in understanding the executability and functional efficiency of the code.In languages like C, C++, C#, or Java, a statement ends with a semicolon (;). And in languages like basic and VB, several statements can be added with a colon (:). Thus, the way it is done differs, but the logic remains the same.The executability (XQT) is calculated by dividing the number of executable statements (STMTX) by all the statements (SMT).Here are some specifics of this method:

  • Counting statements provides insight into how the arrangement of statements affects the flow control within a program. Loops and conditional statements show you how many times a code section can be executed based on the scenario.
  • You can identify the different code branches based on the multiple paths a code could take in each iteration. 

While this does provide code complexity information, it still needs to be a fool-proof method. Factors such as data dependency and error handling can hamper the executability of the code.

IL Instructions 

When measuring developer productivity, it's crucial to select the appropriate metrics. Simply counting lines of code may not be dependable. Instead, experts advise measuring the number of executable statements within the runtime environment, which is a more comprehensive and precise comprehension of progress.Here are the steps:

  • Compile the code: Use a language-specific compiler to transform the high-level code (e.g., C#, Visual Basic) into an intermediate language (IL).
  • Obtain the IL code: After compilation, you'll have an assembly or executable file containing IL instructions.
  • Analyze the IL code: Open the IL code using a text editor or an IDE that supports IL syntax highlighting. You'll see a series of IL instructions representing lines of code.
  • Count the lines: Simply count the number of lines in the IL code to determine the total lines of IL code.

Following these simplified steps, you can easily count the lines of IL code in your program.

Do you need to count lines of code?

Counting lines of code has been a long-time metric; however, every tool and method gives different answers.Using it as a tool for productivity can be problematic because it is not comparable or fair unless you compare the same team’s code within the same team for the same code, language, and style.Here are some more points for you to consider:

  • One developer may write concise code, and another might write more extended code to accomplices the same task. If LOC is a metric, then you might not be fairly judging the quality of their code. 
  • Lines of code are reused through existing libraries, and the rest is written to achieve the desired outcome. However, in such cases, you cannot ignore the reused code nor determine it as original. But that doesn’t negate the developer’s efforts. 
  • Productivity for developers is beyond writing code. Planning, testing, debugging, peer-to-peer reviews, and collaboration can take much time. Therefore reducing productivity to LOC will not be a fair assessment. 

LOC can give you glimpses into code complexity, code length, and executability, but that’s where its importance should stop. Typo’s CEO and Founder, Kshitij Mohan, says, “Measuring developer productivity solely by lines of code is like assessing a painting by its brushstrokes. It focuses on solution complexity rather than the complexity of the problem at hand. And like most metrics, it means very little without context.” Therefore, we believe you can count the lines of code all you want, but don’t use it as a metric to determine which code is better or which developer is more productive. Use it as intended – as a metric to help you along the way.

Programmer to Manager - How to make the transition smooth?

Moving to a different role in your career is always exciting, but that doesn’t mean you can’t also have some self-doubt and anxiety. As a programmer, your responsibilities are more focused on your deliverables and some amount of collaboration with your team member. However, as a manager, your duties will look different.

Therefore, in this blog, we break down some tips to make the transition from a developer to a manager smooth for you.

Six tips for transitioning from being a developer to a manager

Do it as a trial

Moving from being a programmer to a manager can seem daunting, but it's not necessarily a one-way street. With the right approach, you can transition safely using a trial period, and this allows you and your manager to assess if the new role suits you.

It's also beneficial to develop your soft skills during this time by mentoring a junior employee. This is an excellent opportunity to experience management and take responsibility for someone's career growth.

Working closely with your mentee enables you to evaluate your suitability for a management role without formal commitment. If your mentee responds positively to your mentorship style, it can be a strong sign that management is a good fit for you. Remember, this is a journey, and it's okay to take your time to determine if this is the right path for you.

Understand the change in perspective needed

As someone who understands the ins and outs of software development, you know that producing quality code and delivering outstanding products requires the collective efforts of your team.

As a manager, your role is pivotal in ensuring that your team has all the resources needed to succeed. While hands-on work may still be necessary, a significant part of your job involves managing people and projects. This could mean supporting team members who may be going through a tough time or encouraging someone contemplating leaving to stay.

It's a challenging experience that requires emotional investment, but it's crucial to remember that your efforts play a significant role in keeping your team happy and productive. Remember, as a manager, you're not just overseeing a team but also responsible for their well-being and success.

Prioritize communications skills

In today's hybrid or remote work environment, your communication skills are more essential than ever, especially when it comes to writing. As a manager, you spend a significant amount of time typing away on your keyboard, exchanging and managing information. To sharpen your communication skills, it's essential to set clear, measurable goals around how you respond to emails and messages.

As a new manager, you'll quickly learn that a timely response is often more valuable than a delayed one that's been meticulously crafted. Finding the right balance between timely and thoughtful communication is critical to effective management.

Additionally, as a manager, you must be more empathetic in your communication. This skill isn’t merely about language; it’s also about the tone you use and the words you choose while communicating. It will allow your team to be more transparent with you and aid in a more cooperative team spirit.

Accept that you will be coding less

As a manager, it can be a real challenge to balance your time between overseeing your team's work and getting your hands dirty with coding. While you have a range of important tasks to manage, such as setting project goals and managing resources, these duties can often limit the time you have available for coding, which can be frustrating.

In addition to these managerial tasks, you may also find yourself supporting and mentoring your team members, engaging in strategic planning activities, communicating and collaborating with stakeholders, and managing administrative tasks. All of these activities require your presence and engagement, which can further limit your time for coding.

It's important to remember that the amount of coding you do as a manager can vary depending on the size of your team, the nature of your projects, and the structure of your organization. In some cases, you may still have opportunities to contribute code on a limited basis, particularly in smaller teams or more hands-on managerial roles.

Even though you may code less as a manager, your technical expertise and understanding of the development process remain incredibly valuable in decision-making, architectural discussions, and providing technical guidance to your team. So, don't worry, you may not be coding as much as you used to, but your contributions are still significant and appreciated by your team.

Learn to trust in your team more

Establishing trust within your team is crucial as a manager. It's essential to provide your team members with clear instructions and expectations while assigning tasks based on their skills and expertise.

Ensuring open communication is key, and creating a safe space where team members can speak freely without fear of judgment or backlash is essential. Because remember when you were a developer and maybe someone didn’t trust you enough or when you felt micromanaged? Yeah, you don’t want your team members to feel that way.

Giving them the freedom to make decisions and solve problems within their areas of responsibility is essential too. Also, don’t forget to celebrate their accomplishments, support professional development, and practice transparency are all vital components to building trust.

Remember that trust takes time to develop, so lead by example and show your team members that you trust their abilities and support their professional growth. With these efforts, you can create a positive and productive work environment for your team to thrive.

Become better at time management

As a manager, managing your time effectively can be a challenging task. Unlike individual contributors, you may have limited time to focus on creative problem-solving. This means you must protect your team members' time by minimizing unnecessary meetings or interruptions. To ensure maximum productivity, many managers schedule all internal meetings on a specific day of the week. As a great manager, you can get into the "flow" state quickly. By working in shorter blocks of time, usually around 20 minutes, and focusing on one task at a time, you can achieve this. By switching between tasks without losing productivity, your team can benefit from a positive and productive work environment.

Take the leap of faith from programmer to manager!

A new role can be daunting, but if that’s what you want, then it can also be an exhilarating experience. Remember always to keep learning and focus on your team; you will know how you are doing as a manager in how they collaborate with you and each other and how openly they communicate with you. It can be tricky initially, but by improving, you can surely be successful.

While thinking about how to be a better manager, you can also include tools that can help you and your team. A platform that allows engineering teams to maximize productivity and reduce stress will be a game changer for your new team. Typo can be your friend in this process; you can schedule a demo to learn how!

How to become the #1 product on Product Hunt

‘Product Hunt’— a popular destination for startups, early adopters, and investors. It is considered to be a go-to platform that turns your product into a business if done right.

Considering that, we launched ‘Typo’ on 22nd February 2023 on Product Hunt.

To our surprise, it exceeded our expectations and we became product #1 on launch day with ~2000 upvotes. But, that’s not all! We also became the #1 product of the week and #2 product of the month.

It not only gave us 300+ signups globally but our website traffic was also boosted by 8x.

How to become the #1 product on Product Hunt1

In this article, we have shared our extensive learning that made our product a success. Hope it helps everyone who is planning to launch their product soon on a product hunt.

Key strategies mentioned below for successful product launch at Product Hunt:

  • Why choose Product hunt for launching your product?
  • Setting your goal for the launch
  • Pre-launch Strategy
    • 3 months before the launch
    • 1 month before the launch
    • 2 weeks before the launch
    • 1 week before the launch
    • 1 day before the launch
  • Launch Day Strategy
  • Post Launch Strategy
  • A few tips to be kept in mind
  • Conclusion

Why choose Product hunt for launching your product?

We are proud of how ‘Typo’ launch became a huge success. But, it wouldn’t have been possible without the Product Hunt platform. We prepared everything for our launch, the Product hunt gave us much-needed attention and visibility.

  • Enhance company reputation and visibility: Since we were the #1 product of the day, Product Hunt featured us in their newsletter. It further increases our validation and visibility. The top 3 products are usually featured in their blogs and social media channels. It let others know that the product is worth checking out and help in grabbing the right people’s attention.
  • Exposure to relevant personas: This community-driven platform attracts early adopters in the tech ecosystem. This allows us to network with them and expose our product to them.
  • Genuine feedback: When a different set of communities got to know our product, they shared honest feedback. What they liked about it and what needs improvement. Since most of them are early adopters and beta testers, we got real-time feedback about Typo. We did take it on a good note and promise to make changes accordingly!
  • Acquire potential customers: And not to forget, it helped us to get target users too. Since the product hunt gives you the option to choose categories we are interested in (and our product was on the top on the launch day), it helps us get the sign-ups from the right clients for Typo.

First things first: Set your goal!

Before you start with the pre-launch preparation, know what your goal for your product is. I.e. Get clear on what outcome you want to achieve!

Our main aim was to find early adopters who can give us product feedback.

Following are the few objectives that you can choose from:

  • Increase customers and followers
  • Attract investors
  • Find product-market fit
  • Feedback solution
  • Earn the PH badge for marketing purposes

P.S: Choose the goal that will be beneficial for your product in the long run.


Now, as you are clear about your goal, you can start with pre-launch preparation.

We set aside 3-4 months for pre-launch time. We jot down the entire plan and created visuals and content. Everything was done during this time.

3 months before the launch

Ensure that the product is ready: Who would like to give the new users hard time while they test our product? Nobody, right?

The first thing we checked was that all the features in our product are working fine. We tested it constantly. Also, if there are any bugs, we ensure to fix them on a priority basis.

We also ensure that the website is appealing and has a smooth user interface. Our CTA needs to be visible. Also, everything about the software should already be on the website.

Makers need to be active in the product hunt: Makers = The ones who create the product and launch them on the product hunt.

Ensure that the makers are active and responsive prior 3 months before the launch. By this, we didn’t mean to keep promoting your product. But, you need to try out new products shared on the platform, share feedback and ask questions to the creators.

In short, you need to take part organically in the platform. Ensure that you are not active only for the sole purpose of launching your product. Be deeply involved in this platform.

For us, it has been the most important aspect of our launch time. Our makers were constantly engaging with other creators and sharing their feedback. And in the end, it was all worth it!

1 month before the launch

Decide the time and date beforehand: The product hunt homepage is set to 24 hours cycle. Hence, deciding the time and date is the crucial aspect of the launch day.

We decided to launch our product on 22nd February, Wednesday at 12:00 AM PST. Let us break it down for you to understand why we choose this particular day and timing.

As mentioned above, we aimed to acquire early adopters to get honest feedback. Tuesday, Wednesday, and Thursday are considered to be the perfect days for the same. Hence, Wednesday it was.

The product hunt homepage refreshes at 12 AM PST every day. So, we decided to make it live at this time. It will ensure that users will get enough time to review and experiment with our product.

Note that, posting after 9 AM PST is a big no-no.

Get your team on the same page: Product hunt launch is a team effort. Ask your team members to be actively engaging on this platform. Let them know how their efforts can contribute to the success of our product.

Make them understand what you are doing and assign the roles accordingly.

Example: Who will be in charge of content planning?

Who will be posting on social media channels?

(This particular part we will be covering in the next section)

We created a slack channel where we discussed everything regarding our product hunt launch. It allowed us to be aligned with everyone on our team. If there are any suggestions from their side, they can discuss them openly in that slack channel.

2 weeks before the launch

Have content strategy planned for the next few days: The content strategy plan is the most overlooked yet important part of the launch. Since, the next few days will be quite busy, prepare a content strategy 2 weeks before the launch. We did the same and then assigned roles to the different members of our team.

You need to prepare and post individual content on social media channels. It includes Reddit communities, Discord channels, Facebook and Telegram groups, and many more. Also, make sure that you are not spamming on any of these platforms. As it could harm the product even before its launch.

Create a coming soon page for your product: Schedule your launch on Product Hunt at least 10 days before. It further allows you to create a coming soon page for your product. After this, you can see the CTA of ‘Notify me’ on the page.

Anyone clicking on this will get a notification via email about the launch of your product. Try getting as many followers as you can get before the launch day. So, you are assured about the early upvotes on your product when launched.

Identify hunters of your product: Hunter: The early adopters of the product who can ‘hunt’ the product and show it to the rest of the community.

Having a hunter is not a necessity, but it can bring a lot to your table. Their followers also learn about your product, increasing engagement and visibility.

Kudos to Kevin William David, a well-known hunter who agreed to hunt us on a product hunt. This was another major factor in the success of our product.

If you are looking out for the hunter, check out their previous hunts and pitch your idea to them. You can reach out to them via email or Twitter. Try identifying your hunter at least 10 days before the launch. You can find the hunter for your upcoming launch here.

Besides this, self-hunted products can also be considered.

1 week before the launch

While major work is already done, here are a few other checklists that also need to be kept in mind.

Set the right positioning of the product: The description is the most important part of your Product Hunt launch. It should be specific and have a clear message about your product.

  • Title: Name of the product
  • Topics: 3 or more topics to be added
  • Description: < 260 characters
  • Tagline: < 60 characters
How to become the #1 product on Product Hunt2

For the Typo page, we wrote a description that is to the point and short. We answered the two major questions:

  • What does our product do?
  • How it can help your organization.

Ensuring that it is well-optimized and connected to our unique value proposition. As it resulted in driving organic traffic to our product.

Decide visuals for the profile: Visuals attract a lot of attention. Create appealing images, GIFs, and launch videos to add to your product hunt profile. Make sure they are of high quality and clarity in messaging.

How to become the #1 product on Product Hunt3

The visuals we created for our page have a minimal design yet clearly describe our product’s features. Our launch video includes all the important information about our product that helps users understand our product in-depth which further, assists their experience.

You can also add image/video screenshots to your page. Also note that, if you are using a GIF image as a thumbnail, it shouldn’t be flashy.

  • Thumbnail: 240 * 240 pixels
  • Videos and images in gallery: The image should be 1270×760 pixels. For videos, only YouTube links are supported.

Add PH widget to your website: This will act as an indicator who still haven’t heard of the launch yet. And even for those, who want to learn more about the product.

Keep a check on website traffic: While you have already created a website, it’s important to keep a check on how much traffic it can bear. (Just in case your product goes viral!)

1 day before the launch

You can keep this day flexible. As the launch day could be your no-sleep day. (Since 24 hours are crucial for your product)

On this day, you can re-check if everything is on track for tomorrow. Don’t keep anything for the last moment.

Launch day

This is like a 24-hour battle. Here, you are competing with various products that are launching on the same day. Make it worthwhile and for that, you need to be active throughout your day.

Involve every member of your team: Your team is your biggest supporter and cheerleader. Make them your brand evangelists so they promote the product in every way possible. But, also make sure they have explored the platform in advance. So, they know what and how it needs to be done.

You can also assign duties to them in advance so they don’t get lost at the last moment.

Also, don’t forget to let them know that they need to ask for support, not for upvotes. Since product hunt is strict about its guidelines and can report them as spam. (You don’t want to see any of your team members’ efforts go in vain.)

We are a team of 15 members and with our combined efforts, we became the #1 product of the day. If we as a small team, can do so, we assure you can give it a shot too. Trust us, size doesn’t matter. All it matters is your dedication and efforts.

Don’t reach out to your contacts all at once: This is a 24-hour activity. Don’t reach out to everyone altogether. You can divide your outreach into various parts.

For example:

  • In the first 3 hours, you can reach out to your family and close friends.
  • In the next 3 hours, you can ask for support from your friends and ex-employees.

And so on…

You can also ask a few of the team members to upvote early and some of them later. But, make sure that they are members for a decent period before the launch. Since creating new accounts for upvoting on the same day of the launch can again be considered spam.

No fake accounts as well! Since it can lower your upvotes or even avoid your product from being visible on the homepage.

To know your product and competitors’ performance on the product hunt, check out this link: https://pw2.akkio.com/ .

Create buzz on social media platforms: Just like how active you are on the product hunt, the same goes for social media platforms too. You need to let the people know that your product is now live.

A few of the social media channels that we used are:

  • Linkedin
  • Reddit
  • Facebook
  • Instagram  
  • Twitter
  • Telegram
  • Discord
  • Whatsapp

We posted hourly updates on LinkedIn about how many upvotes we are getting. Either from our product’s page or a team member’s account.

How to become the #1 product on Product Hunt4

We also posted BTS on our social channels. So that the audience can connect with us.

In Reddit and discord communities, we shared that our product is live. So, that they can support us and give us honest feedback.

In short, you need to make a lot of noise about your product on D-day. But, again make sure that you are not becoming spammy.

Be responsive on product hunt: Makers’ work doesn’t end with releasing their product. You need to respond to every comment and feedback on your product.

Keep interacting with them to learn how you can deliver them an even better experience. As engagement helps to bring visibility and recognition to your product.

Ensure that your answer are insightful & helpful for the users. Also, don’t forget to thank early adopters and hunters for trying out the products.

How to become the #1 product on Product Hunt5

These responses and feedback can help in prioritizing your product roadmap. And can create a smooth user experience in the upcoming future.

Seek support from other tech startups: We work in a co-working space. Hence, we leveraged it to gain support from other tech startups working there where they shared their honest feedback and opinions about our product.

How to become the #1 product on Product Hunt6

So if you are too working in a co-working space, it’s the sign.

Create a pre-launch and launch plan on google sheets: It’s not possible to remember everything regarding your product launch. Hence, it is advisable to prepare a detailed plan in advance on google sheets. (Or any other application that suits you well).

We created an in-depth plan that was shared with every team member. It made our product launch easier since everything was in one place.

How to become the #1 product on Product Hunt7


Your product is now live. But, this is not over yet. You now need to ensure how much users are liking your product and what are the improvements to be done.

In other words, the Post-launch period is all about analyzing your product and making changes accordingly.

Thank everyone who support your launch: We became the #1 product of the day and our happiness seemed no bound. But, it wouldn’t have been possible without people who supported Typo.

The first thing we did after launch day was to express our gratitude to them. We let them know how much we appreciate their support.

And this isn’t about being the top product on the platform. Even if we haven’t been one of them, we still would thank them for their support. Since they took out their time to help us out.

Also, make sure that you personalized your message accordingly. You can also use social media channels to thank your supporters.

Analyze your launch: No matter how well we did on the launch day, the real game begins after it. We checked what really worked for us and what did not. We tracked our Product hunt statistics that includes upvotes, comments, and referrals. How many signups did we get and what do users usually expect from us? We did detailed analyses of our product on the platform.

Not to forget, we also keep a check on our website through google analytics too. We tracked website traffic during and after the product hunt launch, time on site, and bounce rate.

How to become the #1 product on Product Hunt8

Since you are creating a product for the long run, analyzing every aspect of your product is crucial.

Track user usage: We prepared a questionnaire for tracking the beta users’ feedback. A few of the questions we include were:

    • How did they find our product?
    • How was their onboarding experience?
    • What did they like most about our product?
    • What needs improvement?

We kept the questionnaire short and crisp. And so should you. We also tracked what features are users using, what they are finding difficult, and many more.

Ensure that you are transparent with the users about the tracking process. And also, you act on the insights as early as possible.

Keep promoting your product subtly: Social media channels are a great way to reach out to a wider audience. But, you don’t have to keep promoting your product directly always.

After the product went live, we shared the BTS of launch day – How fun yet challenging it was. We also posted a video thanking our supporters, creating memes around it, and so on.

How to become the #1 product on Product Hunt9

We just make sure that we aren’t only asking people to try out our product. Rather, educating them, informing them about features, and so on.

We also started our blog section where we inform our target audience regarding engineering metrics, developers’ burnout, engineer managers, and so on.

A few tips to be kept in mind

Ask for support, not upvotes: Although, we have already mentioned it before. But, this is an important reminder for everyone launching on product hunt. Asking for upvotes can lead to more spamming that can trigger your algorithm. As a result, it can drop your product rank or remove it from the homepage entirely.

Ask for feedback, comments, and opinions, and help to spread the word. PH believes people should upvote and comment because they authentically like a product, not because they’re peer pressured into doing so.

New users shouldn’t sign in on launch day: New relevant users in your network should avoid signing in on the same day and upvote only on one product. Ensure that they are already active and engaging with other creators and communities.

Don’t spam on social media: Ensure that you are not spamming on your social media pages as well. This can come across as spammy or manipulation and hurt your product’s credibility.

Get everything planned: Don’t keep everything for the last moment. Jot down important tasks before launch. Also, even if you want to experiment, plan it before d-day.

Avoid bots for upvotes: Never use bots for upvotes. The product hunt platform will automatically remove them which can lower your upvotes.

Create an FAQ section to answer common questions: You can include common questions in the FAQ section. It includes features, pricing, availability, and many more. This will save the time of both makers and users.

What if you don’t become the ‘Product of the day’?

If you didn’t become a product of the day, it doesn’t mean your product will not succeed.

Sharing the tips mentioned above may not guarantee you become #1 on the product hunt. It’s about how well you understand your product, audience, and insights.

Also, keep in mind that in the long run, your aim is to reach the target audience.

You can still share your product on social media channels and engage with the community.

All the best for your launch!

Note that what worked out for us may not work for you. So, be flexible about the tips mentioned above and see what is right for you.

It may take a lot of time and effort, but it will be all worth it.

All the best

How to become the #1 product on Product Hunt10

Ship reliable software faster

Sign up now and you’ll be up and running on Typo in just minutes

Sign up to get started