DEV Community: AnalyticsVerse

Developer Productivity - How to measure it?

AnalyticsVerse — Sat, 04 Nov 2023 12:12:13 +0000

Humans are inherently cognitive misers and we have a tendency to solve complex problems in simple and least effortful ways. And that’s what we have been doing with “developer productivity” by taking the easiest available ways to measure it.

First thoughts when you hear “developer productivity”?

I bet it’s something negative, and no doubt this is almost a taboo amongst development teams, as leaders are often scared that having a conversation about this would make the team think they are being micro-managed or that there’s a lack of trust. Two reasons why:

The way developer productivity has been misused by engineering leaders and is being misused as we speak.
“Developer productivity” is not a formula, and we don’t thrive in uncertainty, so we choose to either take up the easiest path or just stay away from this.

Just think about this, there are billions and billions of dollars spent on development teams every year and if there was a one fits all way to measure developer productivity, would it have been still a mystery? Or would you be even reading this blog?

PS: If your goal from reading this blog is to measure your most productive developers or get that one number that helps you promote and fire developers, please turn away, as you are in for disappointment.

Then should we even try to measure developer productivity?

Yes, absolutely!! Because developer productivity is not only about improving engineering outcomes but also ensuring the satisfaction and well-being of the team. And often productivity indicators will also help uncover bottlenecks in development processes and challenges with the working environment and culture of your team.

One of the most successful basketball coaches Phil Jackson puts this brilliantly as

“The strength of the team is each individual member. The strength of each member is the team.” — Phil Jackson

And in the context of development teams, every team’s success is dependent on the fact that each developer is performing at his / her best and constantly contributing towards the success of the team.

Okay, now how should I measure developer productivity?

Two fundamental pillars to maximize your chances of being successful in measuring developer productivity.

Never reduce productivity to one single metric

Measuring developer productivity is difficult as we are trying to measure humans who are involved with logical and creative tasks. And us being cognitive misers try to reduce productivity to one metric — and let me state the obvious, that this model WILL fail.

Rather, trying to capture productivity across multiple dimensions and making use of something like the SPACE framework (S- satisfaction and well-being, P — performance, A — activity, C — communication and collaboration, E — efficiency and flow) can assist dev teams in measuring developer productivity the right way.

Communicate with the team

There’s a very common myth, that developer productivity is only for managers. This cannot be further from the truth. Research suggests that the perception of developer productivity is significantly different between the developer and the managers. As most developers correlate higher productivity with higher activity, whereas most managers relate productivity to performance and efficiency.

Source: https://arxiv.org/pdf/2111.04302.pdf

This stark difference between the perceptions can only be eliminated when dev teams have a conversation about what productivity means for them and what are their true intentions in tracking it. This helps in bringing clarity about why is this important, and how should we measure it, and also eliminates reservations most dev teams have like, Is this the number that decides our appraisals? Or are we doing this because the leadership doesn’t trust us to get the job done?

Do’s

Use the SPACE framework to track developer productivity across multiple dimensions.
Communicate the intentions with the entire team.
Use productivity measures to identify areas of improvement, and eliminate bottlenecks.

Don't's

Reduce productivity to a single metric.
Create secretive measures to track productivity.
Use a metric as the only indicator to decide on appraisals.

Developer productivity metrics

Now let’s look at some developer productivity metrics to track across the SPACE dimensions.

Satisfaction and well-being

A highly satisfied team is a highly productive team. And one of the biggest indicators of a healthy team and working culture. However, satisfaction is an abstract concept, and forget metrics, if someone asks you “How satisfied are you?” I am sure you will think for minutes before answering this question on what satisfied means for you and how to quantify this. And we understand capturing this aspect with numbers is extremely difficult. Thus what you see here are proxy metrics that try to best capture different aspects of the satisfaction and well-being of a developer.

Work completion
Our brain releases dopamine whenever we complete a task, which causes us to be satisfied and motivated right after a task is completed. Thus having a high work completion percentage compared to what was committed will make a developer feel highly satisfied that he/she is able to timely complete what was committed and contribute to the team’s success.
Extra hours worked
Busyness is not a means to accomplishment, but an obstacle to it
— Alex Soojung-Kim Pang
Working extra hours ≠ Higher productivity, actually, it’s the other way, where Working extra hours is one of the biggest factors contributing to developer burnout and hampering their well-being. Tracking extra hours worked, like the number of weekend hours or late-night hours put in can help you in understanding whether a developer is happy and doing well in the current working environment.
Disengaged
The most common indicators of dissatisfaction and burnout are getting disengaged from the team and team activities. One of the ways to measure how disengaged a developer is by measuring a change in the general response times by the developer towards team activities like code reviews, or a decrease in interactions or presence in team meetings.
Developer surveys
Often in figuring out the best productivity metrics we forget the most obvious ways, which is asking your team and understanding the team’s sentiment by running and analyzing developer satisfaction surveys. Asking a question like “How satisfied are you? (Rate 1–5)” is the worst way to understand this, however, there could be other questions that help you capture similar information in different ways and dimensions.
Tenure
A great way to track satisfaction across the entire team, you can look at the average tenure of members in a dev team. Taking into account the nature of developer trends, a decent tenure range could be anywhere between 12–18 months. Anything lower is definitely a cause for concern.

Performance

The best way to measure the performance of developers and dev teams is by measuring outcomes and not output. These metrics help us in capturing the quality aspect of work done by developers. And an ideal outcome for any developer would be “to develop a feature with the least reworks, ensuring timely delivery and maximum customer satisfaction”.

Rework
When a developer needs to correct their pull requests or often a task comes back from QA to the developer for bug fixes it is a clear indication that the quality of work done is not up to the expected standard. And this to and fro eventually leads to extended feature dev cycles. The idea is not to have zero corrections and often rework is also due to changing requirements, however, if a developer is facing this abnormally higher than the rest within the same team constraints, it’s definitely a sign of a performance gap.
Timely delivery
An outcome that every engineering and business leader cares about is having predictability in deliveries, as often a lot of other business decisions, customer communications rely on these delivery dates. And to have predictability in the entire engineering pipeline it’s absolutely important that every developer also imbibes this quality. One way to measure this is by seeing how much was completed from the committed tasks across development sprints/iterations by the developer.
Customer satisfaction
Unanimously this is the most important outcome that drives value for any organization and thus has to be true for development teams as well. Customer satisfaction might mean better reviews on the app store or higher uptime and faster response time on your API service or for a platform team it could be the ease of use and least bugs reported on internal libraries used by other teams. And even though customer satisfaction is not only driven by engineering teams, keeping that as an indicator of performance keeps development teams in connect with the real users of what they are building and helps them focus on the right things.

Activity

Activity dimension alone is widely equated to developer productivity, as it’s the one that’s easiest to track. However, activity alone can never be a true measure of developer productivity. Tracking activity metrics in conjunction with other dimensions across different areas of your SDLC process will help you in identifying true bottlenecks and areas of improvement for developers.

Tasks resolved
Activities in this phase help in identifying how frequently and how much a developer is contributing towards development tasks. And given development tasks are always planned as tasks, user stories, or sub-tasks on a project management tool, looking at the total tasks resolved helps in understanding the involvement of a developer in this part of the development cycle.
Pull requests reviewed
Often the responsibility of reviewing change/pull requests is ONLY with tech leads or the managers of a dev team, which is a clear anti-pattern. Encouraging every developer to review more and more code of their peers helps in eliminating review bottlenecks. And this metric would be a good way to identify if a developer is contributing to the review load of the team.
Deployment frequency
How many times a team deploys changes to production systems, helps you understand the speed aspect of the development process. This is also one of the DORA metrics, and research shows DORA metrics also have a high correlation with customer satisfaction and even the profitability of an organization, making this a great measure to track the activity dimension of a development team’s productivity.

Communication and Collaboration

In any development team, the final outcome be it a feature, service, application, or enhancement is always a result of team effort. And great communication and collaboration are the foundation blocks on which highly effective development teams are built. Including this dimension in measuring developer productivity promotes a culture of transparency and information sharing. Some productivity metrics that help to capture this are:

PR wait time and cycle time
If a dev team has great collaboration, it’s clearly reflected in their review process as potentially this is the most bottlenecked development process, as it depends on a contributor to communicate effectively with the reviewer and vice versa. A metric that helps in tracking how well a developer is collaborating is by measuring how long it takes for this developer to start reviewing a pull request after it’s assigned. And in continuation measuring the median cycle time of pull requests helps in understanding the contributor’s communication skills.
Count of members co-worked with
Development teams very commonly have knowledge silos and groups of developers that interact only with each other and not with the rest of the team, this is another one of the classic anti-patterns. Measuring how many and how well a developer is communicating with other team members is a great way to measure this dimension.
Onboarding time for new members
Whenever a new developer is onboarded to a team, they undergo an initial learning curve and understand the business context, and getting familiar with the tech stack, and often are helped with code walkthroughs as well. The time it takes for a developer to make the first impactful change since they have joined is a great productivity metric to capture the communication aspect of a dev team. As a team with great documentation practices, developers who are willing to spend efforts to help the new joiners will enable the new developer to make an impactful change as soon as possible. A good benchmark to strive for is that the first productive output of a new developer is within the first 30 days.

Efficiency and Flow

This is the dimension that captures “getting into the flow” that developers often talk about. Metrics here help in understanding how many interruptions are there within the development cycles and how smooth is the flow of a task from start to end. Frequent interruptions not only affect the developer’s productivity but also cause increased levels of stress and exhaustion.

Uninterrupted development time
It’s absolutely important for developers to have enough uninterrupted time every day to get into flow and invest time in development activities. And of the biggest blockers to this would be team meetings. Often to encourage higher development times, teams adopt a no-meeting weekday or adopt strict timeslots where team meetings can be scheduled. A higher uninterrupted development time doesn’t necessarily indicate a higher productive developer, however, it’s certain that a developer who doesn’t get enough uninterrupted time wouldn’t be able to achieve the required flow for development.
Commit lead time
More interruptions, more handoffs, and tasks too frequently being re-opened in the development cycle are all indicators of bad efficiency and flow in development tasks. And commit lead time captures this accurately as it measures the total time it takes for a change to make an impact on the end users. A comparatively higher commit lead time (CLT) would definitely mean a drop in the efficiency and flow of the development team. CLT is also one of the DORA metrics. More about it here.
Average In progress (WIP) tickets
Context switching is undoubtedly a productivity killer. Having more to do parallelly would always mean it would take more time to complete all and would also lead to unnecessary mental exhaustion.
2 parallel tasks — 20% is lost to context switching
3 parallel tasks — 40% is lost to context switching
- Gerald M. Weinberg
And WIP tickets beautifully capture how many tasks a developer is working on parallelly. Tracking this productivity metric and trying to keep it always < three tasks is a great practice to start for your dev team.

Change Involvement

When you look at metrics to improve developer productivity, the action that will help you drive change will be a change in your development processes. And measuring how involved and engaged a developer is with the changes the team is driving helps in understanding the effort that everyone is spending to correct the team’s processes. And every process change can have a metric related to it, that captures how well the process is being followed, and tracking leaderboards across these metrics can help you in gamification and understand which developers are contributing well to the process change initiatives.

That’s all folks!

We saw how developer productivity is very commonly misinterpreted as a single metric or with metrics that are easy to track rather than the actual ones that matter. And it’s absolutely crucial that we track developer productivity and take inspiration from frameworks like SPACE to take a holistic approach to developer productivity. And it’s best to start with only a few metrics, but it’s absolutely important to select these metrics from at least three different dimensions. We have talked about an exhaustive list of dimensions and many metrics in each, and now it’s upon you and your team to figure out the right dimensions and the right metrics in them that would be most impactful.

TL;DR: (thanks to ChatGPT)

Measuring developer productivity requires a holistic approach, focusing on multiple dimensions rather than a single metric. The SPACE framework (Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency, and flow) can assist in capturing productivity accurately. It is important to communicate with the team to align intentions. Metrics such as work completion, rework, customer satisfaction, code impact, PR wait time, uninterrupted development time, and process change involvement can provide insights into developer productivity. Taking a comprehensive approach will improve outcomes, team satisfaction, and process efficiency.

And if you are looking for a platform to track developer productivity that’s built on these ideologies, give AnalyticsVerse a spin here.

Daily standup meeting: ways to keep it short and effective

AnalyticsVerse — Tue, 13 Dec 2022 13:58:41 +0000

Developer teams are no strangers to daily standup meetings. Their success in increasing collaboration and visibility has led to their adoption in different types of teams and projects. Every day the whole team has a standup agenda meeting where developers and other team members proactively align with the project and delivery goals, share progress with the team, and be on top of blockers.

There are, however, developers who despise standup meetings because they are hyper-vigilant about even the most subtle indicators of unproductivity. They dislike regular standup meetings because they see no advantage to their work. Instead, they think that the daily meeting has little use to their skills and productivity and they choose to work on projects rather than attend meetings.

However, when run effectively daily standups can be a huge factor in making significant progress in projects and eliminating blockers quickly. This is certainly a more proactive approach to leading dev teams rather than waiting for things to happen and then realizing things are going bad and having to fix them with no time in hand. Whether you are a scrum master or an engineering manager or a developer, we have created a guide on how to run a short and effective standup and things to avoid while running standups in great detail in this blog. Keep on reading!

What occurs at a standup meeting every day?

A daily standup meeting mostly lasts about 15 minutes and is often held at the beginning of the working day. Daily scrum meetings are attended by the development team, the scrum master, and the development manager in most cases. The participants vary for different teams and organizations depending on the structure of teams and how they define roles within the organization. Many teams may also not follow scrum and hence will have no scrum masters. Essentially all stakeholders involved in the day-to-day activities of a project must be present in the standup to make it effective. This also enables everyone to have clear action items after the standup. Each team member responds to the following three questions at the daily scrum:

1. What did you do yesterday?

This is nothing but providing an update on what progress you made yesterday on the tasks assigned to you. You shouldn’t go in too deep and too technical while providing this update. Given this is a place where most of your team will be present, it should be looked at as an opportunity to increase visibility within the team and at the same time help managers and other stakeholders understand the progress on different tasks.

2. What will you do today?

By answering this question, you are essentially laying out your plan for the day. Firstly, and importantly it brings clarity to you because when you are answering this question, you are putting in the effort to think about what should be done today. Secondly, it also makes the managers and other stakeholders understand what progress to expect in all the tasks today and helps them re-prioritize tasks if needed.

3. What is blocking your progress?

Answering this will help to identify what will block the task that you are working on to go to completion or progress today. Eliminating these blockers is essential to help manage feature deliveries and to keep them on track. This helps stakeholders to gauge whether things are going on as planned and what needs to be done if they are not going on as planned. Any sort of simple realignment that needs to be done can be done here.

When and Where should you run daily scrum meetings?

For teams that are working out of the same office, it is better to have standups at the same place and time everyday. Ideally, it should take place in the morning so that everyone can start their days with this. But this gets tricky with remote teams post-pandemic and for teams with members from different time zones. In these cases, you may be tempted by the idea of having asynchronous standups. But we think it shouldn’t be done even though the benefits of doing so :). For the simple reason that standups give a great opportunity to increase visibility within the team and helps to keep everyone in the loop. You involve everyone in decision-making by doing standups and fostering a collaborative environment within the team. Efforts should be made to work out a convenient time for everyone on the team for a standup meeting and it should be done virtually through zoom/meet if needed.

7 Tips for Making the Most of Your Daily Standup Meetings

1. Start with clearing out what a standup meeting is and is not

The standup’s primary goal is to improve visibility and project flow through faster feedback. Every 24 hours, feedback boosts project velocity and allows the team to make immediate modifications to keep the project running smoothly. On the other hand, it is too late if you wait a week to get the inputs you needed seven days ago. It is supposed to be short and not meant to run more than 15-20 mins. Any longer discussion can be done with subsequent meetings with a limited set of people who are needed for the discussion.

2. Stick to the Start Time

Meetings should start at the scheduled time every day, and the schedule should be strictly followed even if some team members are late. That team member could also be you as a manager. It just doesn’t make sense to have the whole team waiting on a single member and all the more reason for you to be punctual in these meetings. Additionally, accommodate team members for whom the standup time is inconvenient and who are not able to attend standup meetings regularly due to this.

3. Prepare your questions to ask during the meeting

As a manager or a scrum master, you should decide beforehand what questions you need to get answered in the standup in addition to the standup agenda. Additionally, throughout the meeting also try to figure out blockers and how to resolve them.

Furthermore, meetings post the standup are better for in-depth technical conversations. . You should intervene when the discussion goes on for long and facilitate meetings post the standup for these critical discussions.

4. Keep the meeting interesting

Since it's crucial to keep meetings brief and to the point, it's crucial for the success of the meeting that every participant participates fully and sincerely throughout. Each meeting should begin by making everyone at the meeting relaxed and included. You might employ a set of rules to choose who would speak next. This would ensure that everyone has an equal opportunity to speak while still having a good time.

5. Prioritize Workload

Everyone aspires to do well. But the workload from competing initiatives frequently overwhelms team members. Daily meetings help make sure priorities are clear and accurate. A team member may be working on the incorrect thing, and important tasks may be unduly delayed if they are overburdened. Make sure team members' priorities are clear, accurate, and manageable at the daily scrum meeting.

6. Prioritize Unresolved Issues

The daily scrum meeting is primarily intended to inform team members about what is being done, what needs to be done, and what obstacles prevent those tasks from being completed. Anything else has to be taken care of apart from this. Define a "parking lot" and list the problems that need to be resolved afterward. Set up a follow-up meeting with just the attendees who have a direct stake in that topic after the initial one has ended. You might keep track of the subjects that should be covered by each sub-division and require a longer discussion. The team members should have access to these "parking lots" outside the daily standup sessions so they may list the issues that need to be resolved. This keeps them present and prevents them from thinking about unrelated things during their regular standup sessions.

7. Use daily scrum meetings to infuse team spirit

This will act as a day starter for most team members. Nothing kills the enthusiasm of team members more than a dull and boring standup meeting. Your job as a manager or scrum master is to also make sure that everyone feels motivated to complete the tasks assigned to them quickly and to collaborate with team members in the meeting. This is one of the things that if done right can create a close-knit and cohesive team.

3 things to avoid in daily standup

Some individuals may feel that standup meetings are a waste of time; however, holding effective standup meetings among teams instills team spirit, enhances productivity, and allows you to discuss challenges you're encountering in order to achieve your goals. If you go further, you'll find that this is typically a result of teams needing to use stand-up meetings effectively, which should be a systematic and quick approach to get a solid feel of what's happening with the team, coordinate work, and eliminate any obstacles.

Numerous factors can cause standup meetings to derail and be badly handled. Still, over the years, we've discovered that most of these "bad habits" can be reduced to one of the crucial standup mistakes listed below.

1. Misalignment

Discussing for long periods about topics that are in no way connected to the work of others. Or maybe something that concerns one colleague in a group of six people. As a result, other team members need more time to listen to unimportant information instead of concentrating on important tasks that can be time-sensitive. Additionally, if you listen to a coworker discuss something for long, for which you are not required to be there, in this case, you risk cognitively disengaging for the remainder of the standup and missing crucial information.

2. Inconvenient Meeting Time

For instance, the daily scrum might be scheduled when you're coding or making progress on a difficult task, which would be disruptive or unpleasant. Coordinating schedules and accounting for calendar conflicts and time zone variances is challenging. Getting the complete crew to arrive at a standup simultaneously should be prioritized at all costs.

3. Too Lengthy

People could have side chats or water cooler banter (instead of work-focused updates). Someone may begin to ramble and take five minutes to finish their thought (it's rather usual for people to offer too much information and support their actions with unnecessary details to sound more impressive).

Final Thoughts

Thanks to the daily standup meeting, your team and you will benefit from having common knowledge of your goals. You can ensure that your team is productive by holding this meeting to ensure everyone is working toward the same objective. Daily scrum meetings are an efficient approach to ensure that everyone on your team is committed. You will have the opportunity to point out issues and suggestions at the meeting.

To further achieve this goal, you can utilize AnalyticsVerse, and look at all data you would get on a daily standup from your team members, and hold productive and seamless standup meetings. This acts as a source of truth and helps to objectively look at how things stand and in pointing out issues and blockers.

9 Software Development KPIs that high-performing teams track

AnalyticsVerse — Mon, 31 Oct 2022 08:00:00 +0000

Why do Software Development KPIs matter?

The most important thing to have for a successful and efficient team in any field is “direction”. And there is no absolute “right” or “wrong” in it. It's all a relative and contextual concept. And Software Development KPIs (Key Performance Indicators) act as that “north star” which keeps the team heading in the right direction.

Software development KPIs are often confused with metrics. Metrics are numbers representing a fact whereas KPIs are things that matter to an organization. Choosing KPIs without evaluating the effects it brings to your team will do more harm than good. As an example “lines of code (LOCs)” could be a metric but should never be a “KPI” for a software development team.

Measuring the right engineering KPIs helps you ensure you have a high-performing and efficient engineering team which is a real competitive advantage. The definition of “high-performing” and “efficient” varies based on the nature of the business and a lot of other factors. Figuring out these KPIs helps you separate the important from the noise. In this blog, we go over how should you select a KPI for your team and also list the top 9 Software Development KPIs that have worked for other engineering teams.

How to and how not to select a KPI?

1. Always keep team efficiency in consideration and not developer productivity.
Software development is inherently a team concept and selecting KPIs to track at an individual level, will never work in the longer run.

2. KPIs should never be quantitative.
It should focus more on the quality dimensions of your work. Tracking the “count of commits” cannot be a KPI, but “customer satisfaction”, an indicator of the quality of the team’s output is a great candidate

3. First identify important processes then select KPIs.
KPIs are performance indicators of what matters to your engineering teams. Identifying processes that matter to you first and then figuring out the KPIs helps in achieving this. Some engineering processes to consider are planning, execution, code quality, deployment cycles, testing, team health, and user satisfaction.

4. Never “copy-paste” KPIs not even from this blog.
Keeping in mind the nature, culture, and where your organization is headed is very important for selecting the right KPIs. The best way is to learn from what others do and don’t but never replicate them just because it’s working for them.

5. Don’t track KPIs your team doesn’t believe in.
In deciding what software development KPIs are important for your team, you are also figuring out your priorities and telling the team this is important for us. Having wrong KPIs is worse than having no KPIs at all.

6. Start small.
You can’t start by saying these 25 engineering KPIs are important for us. Essentially it's deeming everything important, which cannot be true. It’s okay to take time in figuring out what’s important but not doing it will dilute the value of these KPIs.

9 effective Software Development KPIs

These are some KPIs we have seen work beautifully for software development teams. (order doesn’t indicate importance or its effectiveness)

1. Induction time in a team
The time it takes for a new team member to start making meaningful contributions to the team’s deliveries. This helps in understanding how big is the learning curve for this team, and also indicates how efficient the team is in educating new members about the architecture, tech stack, and development practices of the team. A lower number indicates a smaller learning curve and that new members can start contributing quickly impacting the overall productivity of the team and also the satisfaction of the new team member.

2. Testing effectiveness
This can be measured using a combination of several metrics like the ratio of bugs found in non-production vs production environments, the percent of user scenarios tested in non-prod environments, and testing branch coverage. The primary intention of this KPI should be to ensure that the measures used by the team to test changes before going live are effective and that the overhead of production defects is not slowing the team down.

3. Effective development
It doesn’t matter how many code changes were made, what matters is the effectiveness of the code. Effectiveness is when minimal rework is needed and the team doesn’t keep on adding code debts while adding new changes. Rework sometimes is also an indication of unclear requirements or frequent ad-hoc enhancements. Another good measure to track the effectiveness of your code is what percent of code developed is making an impact on your customers. Tracking this as a KPI helps in setting the notion that effective work is valued over more work.

4. Customer satisfaction
All work done by the engineering team finally delivers new features or better experiences to the end-user. Measuring end-user satisfaction becomes a good measure to indicate whether your engineering team is working with the right mindset. A few ways to track this could be by measuring the frequency of usage of features or can also come from a feedback survey after a new feature launch. Depending on the type of your product and the customer support your org offers, indicators like the frequency of customer-reported bugs and the speed with which customer requests are delivered also play a major role in measuring satisfaction. You can track the velocity of feature requests by looking at their cycle time (from grooming to production deployment). Another very effective indicator is NPS (Net Promoter Score) which is a score of how likely an end-user will recommend your product to someone else. This is tracked using customer surveys and feedback forms.

5. Cycle time
A software development KPI that is widely used and correctly so as it is a clear indicator of speed of delivery. Cycle time primarily helps you understand the agility of your teams and what are the areas where most of your time is spent. For example, if the time it takes to test in a staging environment is more than the development item it is a hint for you to automate/optimize your testing frameworks.

The best way to track the cycle time of any task is right from its inception (planned) to its realization (production deployment). An example of cycle time that paints a complete picture of your development processes could look like this

True engineering cycle time from planned to production deployment
Tracking cycle time as a KPI helps you understand the efficiency of different processes. Sometimes cycle time of different stages may not be accurate to the minute but a comparative view and the overall split across different processes helps you optimize the right areas.

6. Production Stability and Observability
No system is perfect and bugs in software development are inevitable. You need to make peace with the fact that perfecting the development process is not going to help. Having the right observability mechanisms in place to minimize the impact is the best way to tackle this. Focussing on both the speed and stability of your processes is key (heart of DORA metrics ideology). Some software development KPIs that help you understand the stability are:

CFR - Change Failure Rate - percent of deployments that cause a production defect, helps you in understanding how frequently your team occurs an overhead of fixing defects.
MTTD - Mean Time To Detect - the average time it takes for a defect to be identified in production - this represents the effectiveness of your monitoring and observability mechanisms.
MTTR - Mean Time to Recover - mean time it takes for you to fix production defects once you have detected them - communicates the speed with which your team can figure out and fix an issue to minimize impact to end users.

7. Team health and satisfaction
Richard Branson says “take care of your employees and they will take care of your customers”. With everyone still recovering from post-pandemic burnout, this is more important than ever. Ensuring the team is not burning itself out and is happy with the type of work they are doing is the fundamental pillar of having an effective and productive team. Some indicators that help in keeping a track of this are

Everyone wants to work on developing new features and the latest technologies. If your team constantly works on solving bugs and maintenance of existing systems it is bound to cause dissatisfaction among the team members.
Development experience - Is it too difficult to even test one single line of change to your system? Equipping developers with tools and flexibility for quickly testing changes or running small POCs is essential for having a happier team.
Time spent in meetings vs actual work - Often software development teams are faced with “meeting fatigue” where they spend more time in meetings than productively working. Which contributes to burnout and context switches that often could be avoided. Understanding how many meetings teams attend or the percentage of the time they spend in meetings could help you understand the team’s sentiment towards meetings.

8. Documentation and Knowledge sharing
For any software development team to effectively work, knowledge has to be shared widely across the team. It could be in the form of code documentation or component specs, or design documents. In the current scenario, the question is not “if” a team member is going to switch to a different team or org, it’s more a question of “when” - 0% attrition is not possible period. The best way to deal with this is by reducing knowledge silos within your team so that even if a team member decides to leave the “show can go on”. Engineering KPIs covering this aspect include

Percent of your code base that is documented. How frequently are component diagrams or API specs updated could be a few indicators to denote code/design documentation practices.
The number of meetings it takes for a new joinee to understand the system. A high number of meetings would mean there doesn’t exist enough documentation as self-serve for the new team member.
Percentage of your codebase that is known to only one team member. (higher percent = more knowledge silos within the team).

9. Task planning and predictability
Which tasks need to be done, by when, and who’s going to work on them - are key questions that need to be answered in planning a project. All team members may not necessarily be involved in making this decision, however, the team needs to work predictably for the organization's growth. These are a few KPIs that work:

Work breakdown structure - Project management is completely based on how well you break down a task into more manageable tasks - this helps in establishing clarity in what needs to be done and better estimating the time it may take.
Predictability - This indicates what percent of the committed work is completed in a time frame. There are multiple things like ad-hoc requests or production bugs that could affect predictability.
WIP count - Working on multiple things together is optimal, but working on too many things together is never desirable. You can understand the sanity of your planning process by looking at this for a development team.

4 dangerous Software Engineering KPIs to avoid

You should try to avoid these 4 indicators at all costs. They tend to do more harm than good for your development team.

1. Active coding days
This metric in no way represents the quality of the work done by an individual. Everyone’s work pattern could be different, some could take 3 days to understand a requirement and logically map out what exactly needs to be done, but then complete the actual task in a day. Assuming every team member should code daily is a baseless assumption. There are many other things a team does like reviewing, designing, testing, releases, planning, grooming, and helping junior team members amongst others. Tracking coding days as a KPI renders all these other functions useless. And not the right culture you want to imbibe in a high-performing team.

2. Lines of code
This age-old metric is without doubt the worst way to track the productivity/output of an engineering team. Tracking a KPI like LOC indicates that for a task if a team takes 100 lines of smart code is worse than 1000 lines of bad code. No software development team should ever focus on LOCs as a KPI.

3. Sprint velocity
Another very commonly misused metric is velocity. Velocity can be a good indicator of how many planned tasks were completed and also assist in future sprint planning. But never an indicator of a team’s productivity or effectiveness. Velocity becomes a dangerous KPI when it is used to push developers and compare teams. Two teams even in the same organization can have very different estimating standards and tracking that as a KPI of a team’s productivity opens the gate for gaming the system. Tracking velocity as a KPI often results in the team working for a better KPI rather than better work.

4. Stacking developers against each other
It's very common to confuse software development KPIs with metrics to track individuals under the name of “developer productivity”. Engineering KPIs should represent the overall state of a team or a project, never individuals. Above all, comparing a developer with another is the worst thing one can do to improve team productivity. Your team has to contribute towards better engineering productivity using these KPIs and not feel threatened by them.

Going through the process to select the right software development KPIs that matter to your team might be slightly time-consuming but with the right mindset, this is extremely helpful in the long run. Right performance indicators would act like guiding beacons for your engineering team in turbulent times and help you ensure you are headed in the right direction.

AnalyticsVerse helps software engineering teams transform their development processes by tracking the right software engineering KPIs.

10x Tech Lead - What effective technical leads do differently?

AnalyticsVerse — Sat, 29 Oct 2022 08:30:05 +0000

Do 10x Tech Leads exist? Do Tech Leads really matter that much?

Short answer: Yes they do!!

The secret sauce to an engineering team's success is an effective tech lead guiding the team to be on the right track. Without a tech lead the team is really going to carry swords in a battle of tanks. In this blog, we start by defining a tech lead and their responsibilities and explain the important traits of the really effective ones.

Who is a Tech Lead?

A tech lead is a person who will assist the developers with the technical tasks and coordinate the delivery timeline with the manager and other stakeholders. Technical lead in most cases is an unofficial position and sits as the communication bridge between the management and the development team. It’s not easy to be a technical lead as managing the delivery is a responsibility along with his / her personal technical contributions to the team’s deliveries.

The way 10x engineers contribute much more effectively to a team than their peers, a 10x technical lead is someone who ensures the team is making the right technical decisions and guides the team much more effectively than the rest.

Having the right person as a tech lead is really important as it doesn’t matter how hard you are pushing if you are pushing in the wrong direction. A 10x technical lead is going to help you in making the right calls and help you have predictability in the engineering team’s delivery.

Is a Technical Lead different from a Manager?

Absolutely!! A tech lead is mostly an unofficial designation and is assumed by the best-suited team member. While a technical lead is majorly involved with the technical decisions of the product a manager is heavily involved with people management, 1-on-1s, and even appraisals of the development team.

Q: Are you responsible for appraisals of the development team?
A: You are a tech manager.

Q: Do you connect the development team with stakeholders across the organization?
A: You are a technical lead

Q: Does your team frequently seek your advice on technical/architectural choices? Do you question the technical decisions of your team?
A: You are a tech lead.

Q: Do you spend a significant part of your day reviewing others’ code?
A: You are a tech lead.

Q: Are you the most important person taking the decisions when your team is firefighting a production issue?
A: You are a technical lead.

Q: Do you feel you work more than the manager but earn less than him?
A: You my friend, are a true tech lead :D

What makes a technical lead effective?

The fundamental roles and responsibilities of any tech lead remain the same. What differentiates a 10x technical lead is the effectiveness with which the responsibilities are carried out. Whether you are an experienced tech lead looking to grow or a developer wanting to take up this responsibility, knowing these key functions of a tech lead will help you be a “10x technical lead”.

Strong technical know-how

If you are leading a technical team, very strong know-how of technical architectures and engineering systems is a must. Making the right architectural and technical decisions will be a major part of your role. “Technical know-how” is very commonly confused with “complete understanding” of a technology or a framework, which is often not expected. But having strong basics for evaluating design choices is a must.

Technical know-how includes the ability to conduct effective code reviews and instill that quality in other team members. As the team is going to rely on your reviews to ensure they are following the well-accepted coding and design practices. A major time of your day (30-40%) may go into reviewing code and design documents. Having the knack for figuring out the places a design or code may fail quickly is a must-have quality for effective technical leads.

Your team members are also going to rely on you when firefighting production issues. Having someone who will be able to figure out or ask the right questions when things go wrong will help the developers grow. Figuring out places to look at, is not going to be possible without a strong understanding of how the system and underlying frameworks work. For example, you cannot debug a “Heap OutOfMemory” exception without knowing the basics of the Java processing framework and what application objects could potentially be causing a problem in the failed flow. And this needs knowledge of both the fundamentals of the framework and how the application works.

“10x tech leads” are NOT the senior most developers in the team. They are the ones who are the most capable of leading a particular delivery because of their skills. Including the technical know-how needed for this project and are ready to get their hands dirty when needed.

Right communication attitude

A tech lead needs to communicate effectively within and outside the team. The technical lead is going to represent the team in discussions with other stakeholders and it's important that the communication channel is both ways. Where the tech lead knows what strategic decisions need to be conveyed to the team and what blockers or concerns from the team need to be raised externally.

“Right attitude” is key to communication. An effective tech lead is not someone who knows everything but rather the one who can accept when something is unknown and accept better ideas from the team. It’s not important to come up with the best solution yourself but to ensure everyone’s voice is heard and the team settles on the best solution irrespective of who is saying it.

Often people confuse good communication skills with sugarcoating and filtering difficult conversations. Sometimes it's important to correct someone and guide the discussion in a particular direction rather than letting the team debate about it. It’s important to convey the message correctly without humiliating and disrespecting someone. When a group of smart people come together to work as a team, it’s almost certain there will be conflicts within the team. Knowing how to gracefully handle them and resolve them is a characteristic of a 10x tech lead.

Influencing happiness and engineering culture

Guess who a new developer in the team will learn the most from? It’s not going to the manager but from the peers and the tech lead. As the developers are going to work very closely with the tech lead they naturally become the first influence for them even before the managers. And it's important as a tech lead you are mindful of the happiness of the team members and the culture the team is working in.

Being mindful of the team’s happiness is knowing when to ask someone to push and when to take a break to avoid burnout. It’s really important to create a safe and healthy environment for your team, if that means shielding the team from a micro-managing manager so be it.

Technical leads also act as the culture bearer within the team. If the team is seeing a lead work late nights it automatically becomes a norm within the team to work late nights. Similarly, if the lead follows a practice of seeking complete logical clarity in what needs to be done before writing a single line of code, that is what the team will try to imitate.

There is a very high correlation between the happiness and productivity of the team. A healthy working environment is a must, and an effective technical lead ensures one.

Mentorship

Did you know the biggest reason “homo-sapiens” are such a successful species? It is “our ability to form collective intelligence far more superior than of any one individual” - The Secret of our Success.

Applying the same concept to engineering teams, a culture of knowledge sharing and peer help within the team is a trait of all high-performing engineering teams. As a technical lead, it's important to enable this within the team. Sometimes this knowledge sharing and mentoring of developers could come directly from the tech lead or also from other team members that have the right expertise.

Mentorship could mean delegating tasks at the right time. Doing everything, or thinking through all architectural choices is never a technical lead’s responsibility. Mentorship could also be in the form of knowledge-sharing sessions. Team members may have a lot of beneficial information only with themselves, but creating the right platform to share this with everyone helps the team grow together.

Learning from peers and from the tech lead is a great way to introduce the team to newer concepts and keep it challenging for the team. Helping your team members grow eventually makes them capable of making better design choices, writing better code, and helping others. An infectious knowledge-sharing environment within a development team is a sign of a 10x tech lead.

Understanding and sharing the business context

As a technical lead, one inherent responsibility is to also make architectural and technical decisions keeping the context of the organization’s domain in mind. You cannot take architectural decisions like a video streaming platform if you are creating an e-commerce application. It's also the responsibility of a tech lead to not let the team re-invent and learn from others when needed, as they are the ones that are most aware of technical architectures across the organization.

It’s crucial that the technical lead shares the direction in which the organization is headed with the team members, as a tech lead would know most about it as compared to anyone else. No team member would want to just complete a task, but also understand the impact and the logical reasoning behind the change. As an example, if the team is working to reduce the response times of the service, they have to understand why is it important, the extent of the problem, and what changes if it’s reduced.

The concept of “Start with Why” by Simon Sinek is something that applies to a tech team as well. Understanding the functional impacts a change will bring and understanding “why” we need to do it is important for the team to come up with the best solution to the problem at hand. And an effective technical lead ensures every team member is aware of it.

Process optimizations

A tech lead is most closely related to the development process than any other engineering leader. And it becomes their responsibility to understand what areas need attention and to actually facilitate action to improve them. Improvements could be as simple as enabling local testing to optimizing deployment cycles.

It’s important to create an environment where the team members are comfortable enough to share when something is wrong and are able to suggest improvements. Having the right processes in place to ensure an efficient working environment and delivery is as important as taking the right architectural decisions for a tech lead.

Process optimization also means looking at the development activity of teams to figure out where is the team investing the most effort and optimizing it. Here are a few questions that will help you understand the high-level areas of improvement.

Is the team spending more effort on production bugs than new features?
Are you experiencing a high change failure rate (percent of deployment that causes a production defect)?
Is the review process only bottlenecked on a fixed set of people?
Is your team taking more time to review than actual development?
Are your deployment cycles taking weeks instead of days?

A 10x technical lead knows continuous improvement is the only way to build a high-performing engineering team and will figure out ways to improve and act on them.

The effectiveness of a technical lead in these areas is what makes a 10x tech lead. It's impossible to do everything perfectly, but keeping in mind what matters will help a tech lead guide the team in the right direction.

If “Engineering is Magic” the ones leading these teams of “magicians” are the ones that play a significant role in providing the right platform for this “magic” to happen.

Explore how AnalyticsVerse facilitates process improvements and assists 10x tech leads here.

Tool stack for a tech startup

Ankit Gala — Sat, 03 Sep 2022 15:31:33 +0000

I see a lot of blogs about tools that startups use within their teams and founders use for personal use. I always discover new tools through such blogs and am surprised to see the range of tools solving different problems.

For me, I have always tried to limit the number of tools we use within AnalyticsVerse and for my personal use. Reasons for that are:

The more the tools, the more information gets spread over these tools. Hence we try to avoid using tools with overlapping functionalities (Unless there is a huge value that we see in adopting another tool)
Effort goes while context switching between different tools. Having a smaller set of tools helps me focus better.
While bringing in newer people into the team, it is easier to onboard them faster with a limited set of tools and all information being in one place
We prefer using freemium tools having more suitable pricing for smaller teams and that have integrations with our teams channels making it easier to have important things in a single place

I’ve compiled a non-exhaustive list of tools we use at AnalyticsVerse and I personally use:

📧 Emails + Internal Comms — MS Suite with Teams

While I personally would prefer using slack over teams for a better interface, the whole ecosystem with outlook, teams, teams video, onedrive makes it a much more integrated and better experience. Almost all other tools we use have integrations with teams channels.

⚙️ Code + Project Management — Gitlab + Jira

We initially went with Gitlab due to better CI/CD capabilities(pre-Github Actions) and Jira because AnalyticsVerse integrates with Jira and using it within the team gave us a better understanding of it.

🗒️. Wikis + Note Taking — Confluence + Notion

We use Confluence as a wiki extensively to document things that make onboarding easier for new members and high-level designs of our system. While Notion is mostly used for personal note-taking and for collaboration between 2 or 3 team members. There is a clear distinction of what should go on Notion vs Confluence

☁️ Hosting — AWS

We chose AWS simply because we were more familiar with this and for the range of services AWS offers. Also, we have started utilizing teams integration to handle cloudwatch alarms much more effectively now.

🎨. Design — Affinity

We found this to be the best alternative to Photoshop and meets most of our design needs.

💬. Lead Tracking — Monday.com

The ease of use is much better than any other CRM we were exploring and helps us track leads much more effectively. One thing we are still looking out for here is having a single tool that gives a detailed account of all interactions with leads across our different channels and campaigns.

📈. Analytics- Amplitude

This is one tool that I use a lot. Helps me understand what feature is being used more by our users and helps shape the product better.

Hopefully, this information is helpful for everyone who’s starting out and still in the process of selecting what tools you want to use for your day-to-day.

Common technical decisions you will make when building a SaaS product from scratch.

Shharrnam Chhatpar — Sat, 03 Sep 2022 14:27:43 +0000

In the course of building a product, we make technical decisions every other day. These decisions could be small decisions or big decisions. These could be reversible or irreversible decisions. Though there is no technical decision that is irreversible, it’s the amount of effort that makes it going back rather improbable. Architectural Design Decisions that a tech team makes at the start of product building fall into the category of big irreversible decisions.

Once these decisions are made, any tech lead will keep making smaller reversible decisions every other day with a few occasional big irreversible decisions. Here are some of those big technical decisions that we’ve made at AnalyticsVerse.

☁ AWS over Other Cloud Platforms
One of the major reasons why we chose AWS over other cloud providers was our familiarity with AWS. In addition, the amount of resources available on the internet for AWS is sufficient to get anyone up to speed in a couple of weeks.

☕ Java over Python
It is no secret that Java is much faster than Python. Speed of code execution was one of the biggest advantages of Java over Python. This has helped us provide a much better experience to our customers by generating reports faster.

🔢 SQL over NoSQL
Since AnalyticsVerse generates reports by correlating data across different tools such as Git Repositories and Task Tracking tools, all of this data had an inherent relation between them making SQL the go-to choice for us.

🖥 Server over Serverless
With Serverless, there comes the problem of warming/provisioning lambdas. This option turned out to be costlier as compared to running an instance behind a load balancer with autoscaling rules. In addition, the traffic that we serve is somewhat predictable which made not going serverless more suitable for our use case.

⌛ Airflow over Step Functions
Our first choice for setting up our data pipelines was Step Functions. However, one of the founders proposed we could evaluate Airflow. With airflow, we got an inbuilt scheduler as well in addition to being able to set up DAGs jobs. With airflow, we could easily support on-prem deployments from the get-go. We did face a challenge with scaling airflow a few months later, however that is an individual post in itself.

☁ Terraform over Cloudformation
In terms of the effort, it takes for setting up an Infra using terraform or cloud formation we found there was no difference. Terraform provided more control over state as compared to cloud formation and with terraform, we had an added advantage of being cloud-provider agnostic like most of our choices above.

The scaling challenge that I mentioned about airflow above was one such challenge that forced us to start thinking of alternatives. However, being a big irreversible decision, we were not very keen on moving out of airflow (given the effort it would take us :P) which forced us to think of creative ways to solve the scaling problem without having to increase compute power.

Why did I switch from an MNC to a Startup?

Breejesh Rathod — Sat, 03 Sep 2022 14:09:49 +0000

If a year ago someone would have come up to me and told me to quit my safe, conservative job, my reaction would have been, "Are you crazy!?".

But then, an opportunity came up which forced me to think about just that. And I had a choice to make.

But this was not the first time in my short life so far that I found myself standing at the crossroads. And every time, there would be the opinions of thousands of people regarding what I should and shouldn't do. But I have learned to trust my gut above anything else while making these decisions. And here I am today, doing exactly what I had never imagined I would!

Yes, I quit my job at Morgan Stanley to start an exciting new journey as one of the co-founding members of AnalyticsVerse!

In that context, many people in my network often ask me this question - Should I join a startup? Or should I work in an MNC? Well, the answer to that will always be subjective to what you are looking for in your career. But here are some key differences that I have noticed based on, but not limited to, my experience:

This is what I gathered so far, and this is my attempt to give a clear - even if not exhaustive - picture.

I know for a fact that it is going to be challenging. It is going to be an uphill battle. There will be days when things won't work out as intended. And there will be sleepless nights (as Shharrnam will know :P)

I am glad that Ankit, Dharin, and Shharrnam welcomed me into the team.

But I also know that it will be worth every bit of it. It is going to be fulfilling. It is going to be fun. It is going to be a brilliant learning experience. And I will see a better version of myself on the other side. These are the key factors that helped me in making this choice.

Modern Engineering Leadership

AnalyticsVerse — Sat, 03 Sep 2022 13:40:36 +0000

Engineering and technology are at the epicenter of disruption in every industry you can imagine. Engineering divisions could easily be termed as the protagonist leading the role of digital disruption today. And do you believe it’s easy managing a team of these disruptors? Especially with the incessant changes going around, we often tend to question our ability to lead the teams.

In this first blog post, I wanted to share with you a summarized version of the biggest questions around engineering and its leadership and how to deal with it, which we have gathered after interacting with 100+ engineering managers from startups to enterprises.

Whether you are a junior developer or someone who has just moved into a leadership role or a veteran engineering leader, this post will help you understand and navigate through these changing times.

What has changed, and how should you embrace it?

Ironically, engineering or software to be specific has enabled analytics and visibility in a wide range of fields, take for example

You want to track anything within how your product is doing and how a new feature is getting adopted by your customers — Amplitude and Mixpanel have come up with some groundbreaking yet simple metrics.
Start and track how a marketing campaign is performing for your organization? Hubspot and Mailchimp give you the insights you need to define the success or failure of a campaign.
Need to figure out what does your monthly revenue look like, and what your churn is on a subscription business and a lot of slice and dice on your financials? RevenueStory by Chargebee is really simple and easy to use yet an extremely powerful tool.

And so many more, but have we reached that level of maturity in tracking and visibility on how engineering teams and projects are performing? And in case you are wondering, yes, engineering accounts for a substantial cost in so many organizations.

Without visibility on what their teams and projects are doing, engineering leaders are driving a race car blindfolded.

Maintaining a healthy engineering culture is gaining places in terms of priority with engineering leaders, and it becomes even more important when you want to attract and retain the best talent with your team, given the worldwide shortage of developers.

It’s almost impossible to not mention remote work when discussing what has changed. We all expected remote work to pick up in the next few years but no one expected it at the pace that the pandemic has triggered.

By 2025, an estimated 70% of the workforce will be working remotely at least five days a month.

Forbes

And while there are a good number of pros to it, it brings a new set of concerns around alignment, teamwork, and visibility in teams’ work. The last thing any leader wants is to blame remote work for slipping on delivery by a few weeks.

Do you often wonder what should I change to improve?

Every leader is looking for different ways they can improve their team’s performance and productivity. But how does one decide what changes should be done? And will they work?

In all our discussions, one thing we have understood is, that there is no one-fits-all solution possible here. It very much depends on the dynamics of the team and the engineering culture and processes followed within the organization.

Now while I know this doesn’t sound very encouraging and could deter you from tracking anything at all, tracking something over time and iterating this over a period of months and years is a time taking but extremely effective way. Even small measurable progress can go a long way in improving the team’s morale and eventually making the team more effective.

Having a way to detect bottlenecks in the engineering process and figuring out ways to improve them is the best way to adopt incremental change, and engineering managers often complained they are the last to know about these bottlenecks. Have automated ways that proactively help you identify these. Another way to figure out bottlenecks is to have regular and uncomfortable conversations with your team, which keeps you as close to ground reality as possible.

The million dollar question — Is developer productivity measurable?

There is a reason why a dev team’s progress is not measured by just numbers! A developer is a human and evaluating any human performance with any tool or a number is an impossible task. A personal touch along with various developer metrics might be a better way to track developer productivity.

Creating a transparent tracking environment — by being open about the various metrics that are being tracked will create a better work environment. And at the same time, developers should not be stacked against each other, comparing with her/his own past performance to find an upward or downward trajectory is the way to go about it.

Should numbers drive performance rating? Never, I repeat never. All numbers and insights should be used to foster the growth of developers rather than being used as an absolute number to be compared across others. And insights and metrics on developer’s performance could be great conversation starters in your 1–1’s.

I am a new engineering leader, how do I make myself more effective?

Every team has its own set of priorities and dynamics. Understanding what your team needs and what works best for your team is a challenging task. Some prioritize fast delivery of new features, whereas some prefer stability over speed which is justified based on the nature of the product and the features they are delivering.

Build measure learn loop is the best way to lead engineering teams.

A good mechanism to identify what works best for your teams is by experimentation and find the sweet spot for your team, extra importance on experimentation, if you are not bold and settle with what is working for you right now, you may never know what could have been done better.

Another great suggestion, which has even personally helped me is being a part of communities of engineering leaders and managers, where people actively discuss real-world problems and how to deal with them. This post has a list of a few communities which could be useful.

How does my team compare to other teams?

The best way to track a team’s progress is to compare it with its own performance in the past. By creating mechanisms to actively track your progress, engineering leaders can find the right action items to take their teams on an improvement trajectory.

A perfect engineering team does not exist, period! Neither at that tech giant nor at the next hottest startup.

Tracking performance on smaller units like, how your team performs in a sprint, or what could have been better for a particular epic will go a long way in the slow and challenging process of improved performance.

One thing I strongly believe in is ‘You can’t improve what you don’t measure‘. In case you are looking to identify bottlenecks within your teams and track metrics that matter, you should have a look at AnalyticsVerse and how it can be your best assistant in leading engineering teams.

How we revamped our landing page for better clarity and conversions

Dharin Parekh — Sat, 03 Sep 2022 13:13:19 +0000

Recently we revamped our website which is basically the heart of a SaaS product and needs to do a great job of explaining the value one gets out of the platform in a span of 2 minutes or lesser. Having a modern and slick UI, that delivers the right message to the right audience is extremely important to create a lasting first impression on the user.

Here is a summary of a few actions we took.

1️⃣ The first thing we did is go to the community and ask them to roast your site and it’s important to ask for a “roast” and not a generic “feedback”. Some good resources you can use:

https://www.roastmylandingpage.com/
https://roastmywebsite.net/
https://www.indiehackers.com/group/landing-page-feedback

🏚 Our hero (main image) is the most important piece of estate we have, which was originally a generic vector image. We tried to replace it with the use-cases from our platform.

🙌 Revamped our features section to “what do you get”, not only a name change but gives a view into how teams can and have leveraged different features of our platform to solve a problem.

❌ Added a section dedicated to the most common objections we have heard about and tried to express our ideologies there. If your platform is something you need to educate your users about having this section is a must.

🕐 Added a GIF to the platform which shows how quickly can anyone integrate and create their projects on our platform. (Intention was to show users if we can capture the steps in a GIF, it won’t take you more than a couple of minutes to do that)

💬 A professional and personalized chat experience. Switching from a free chat to a paid one. I believe a free one with a banner on the bottom saying the same, doesn’t do good for your startup's reputation.

✍ Added an about us page, describing the team and why we are building AnalyticsVerse. We learned this the hard way when you are a budding startup, your users want to be aligned with your why before what and how.

💳 Optimized our sign-up and login flow to reduce the number of interactions and removed the mandate of credit card details on sign-up (saw a huge number of our sign-ups drop here). Which now seems obvious but was a lesson learned the hard way.

👨‍🦱 Adding case studies and customer testimonials on our website (this is still something we are working on) goes a long way in increasing your credibility.

To come to these action items, we have received decent help from folks in the community as well. A small mention to Palash Wadhwani for helping us out voluntarily and also Pedro Cortés for creating awesome content around landing pages.

This in no way means that we have the most optimized landing page right now, and are still working for a v3.0. But these are a few actions in, hopefully, the right direction.