{"id":6088,"date":"2020-03-27T17:50:18","date_gmt":"2020-03-27T17:50:18","guid":{"rendered":"https:\/\/waydev.co\/?p=6088"},"modified":"2023-02-21T09:39:04","modified_gmt":"2023-02-21T09:39:04","slug":"remote-work-for-engineering-managers","status":"publish","type":"post","link":"https:\/\/waydev.co\/remote-work-for-engineering-managers\/","title":{"rendered":"Remote Work for Engineering Managers"},"content":{"rendered":"

It’s been two weeks since we took action and made working from home mandatory for all the team members. Our top priority remains the health and safety of our team members. We have a responsibility to support our communities through the health crisis caused by COVID-19.<\/p>\n

Moving to a 100% work-from-home policy<\/strong> in such a short time frame is not easy, but there are companies that thrive in a remote environment. The best example is GitLab. GitLab is the world’s largest all-remote workforce, with over 1,200 employees spread across 67 countries. We are one of the few GitLab partners in the Performance Measurements field<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

GitLab has been able to grow continuously because they have a process put in place. One of the key elements of focusing on the process is measuring the process<\/strong>. Git Analytics tools<\/strong>, such as Waydev, help engineering leaders manage remote teams effectively by providing actionable metrics and features that translate into visibility, velocity, and productivity enhancement.<\/p>\n

Waydev’s features help engineering leaders to run nondisruptive daily stand-ups<\/strong>, effective one-on-ones<\/strong> and enable a healthy code review workflow<\/strong>.<\/p>\n

For Daily stand-ups<\/strong>, the Work Log<\/strong> provides a high-level view of your engineering team’s activity, such as commits and pull requests, so both engineering managers and engineers don’t need to waste time on questioning and reporting.<\/p>\n

\"\"<\/p>\n

For One-on-ones<\/strong>, the Developer Summary<\/strong> offers a low-level view of the activity of each engineer, so engineering managers can see what are their engineers working on, spot and eliminate any blocker that might be holding down their team.<\/p>\n

\"\"<\/p>\n

For Project Health Checking<\/strong>, the Project Timeline<\/strong> helps engineering leaders to see how work focus and volume shift over time. You can see whether your engineers focus on creating new code, refactoring old code or on helping others. You are able to view and correlate how events impacted your team\u2019s velocity and performance, and direct your data-driven decisions.<\/p>\n

\"\"<\/p>\n

We divide our metrics into:<\/p>\n

Code-level metrics<\/h3>\n

The code-level metrics provide engineering leaders with insights regarding their engineers’ efficiency and productivity.<\/p>\n

Impact<\/strong> is a way to measure the amplitude of code changes that happen, in a more complex manner than measuring raw lines of code. The algorithm behind the Impact is similar to Google\u2019s Page Ranking algorithm. It comprises multiple data points that translate engineers\u2019 output into both business value<\/strong> and cognitive load<\/strong>.<\/p>\n

\"\"<\/p>\n

Churn<\/strong> represents the percentage of code that has been rewritten or deleted shortly after being written. Of course, nothing works perfectly from the first try, but if this percentage experiences spikes, you might want to analyze that. It might have only been a change in specifications, but it could also mean that an engineer got the requirements wrong, or that a manager wasn’t clear enough. This can help you diagnose issues early and fix them in a timely manner.<\/p>\n

Technical Debt<\/strong> represents the amount of refactoring code done by an engineer. Usually, the process of paying down technical debt is a less shiny process than releasing new features, but it is more complex and it carries a higher cognitive load. Paying down technical debt might enable engineering teams to release a new feature or fix a long-running flaw that had the potential to affect the whole project.<\/p>\n

Code collaboration metrics<\/h3>\n

Code collaboration metrics provide an understanding of the code review process. They quantify the effectiveness of the engineers’ collaborative work and knowledge sharing.<\/p>\n

Review coverage<\/strong> calculates the percentage of pull requests that had been reviewed before being merged. This metric helps you gain a better understanding of your team\u2019s code review process and aids you in spotting unhealthy code review patterns. A low review coverage translates into a higher chance of putting buggy code into production, whereas a high review coverage decreases the chances of buggy code to be put into production.<\/p>\n

\"\"<\/p>\n

Time to Resolve<\/strong> measures the velocity of the code review activity. It represents the average time it takes to close a pull request.<\/p>\n

Sharing Index<\/strong> measures how broadly information is being shared amongst a team.<\/p>\n

We know Waydev is particularly useful for tracking your engineers\u2019 output when they are working remotely, and after seeing increased usage in the regions hit hardest by the virus, we\u2019re taking immediate action to ensure our product is accessible to as many people as possible.<\/p>\n

Through July 15, 2020, we are:<\/span><\/p>\n