Visualizing “Development Productivity”: How to Create a ‘Starting Point for Dialogue’ that Connects the Field and Management
Introduction
In software development teams, many intellectual decisions are made every day, and processes such as implementation, review, testing, and fixing are carried out at a dizzying pace.
However, progress and status are hard to see from the outside, and fundamental issues such as “where are things getting stuck?” and “who is overloaded?” often remain unclear, which can lead to team exhaustion and rework.
We support teams facing these challenges through an approach we call visualizing development productivity.
That said, we believe visualization should not be a mere list of numbers, but a “question-asking device” that enables the team to talk and move forward.
In this article, we will explain in practical terms:
- Why it is necessary to visualize development productivity
- Which metrics to introduce, and in what order
- How to leverage visualization for team improvement
- The concrete content of the support we provide
Please use this as a reference for taking the first step toward overcoming the invisible wall that exists “between” management and the field.
Why is “visualizing development productivity” necessary?
Compared to other types of work, software development is a world where progress and outcomes are extremely hard to see. This is because most development work involves intellectual decisions and thinking—such as “design,” “implementation,” “verification,” and “fixing”—which do not easily appear as numbers or visible forms.
For example, in manufacturing, you can understand the situation on the floor through numbers such as production line utilization and shipment volume. In software development, however, it is difficult to give clear answers to questions like “How long will it take to complete this feature?”, “Where is it currently blocked?”, and “Is the team operating efficiently as a whole?”
In particular, as the team grows or comes to handle multiple products, everyday work starts to generate “intuitive discomfort” such as:
- “We don’t know where things are getting stuck.”
- “It feels like reviews are slow, but no one is sure.”
- “We’re working hard, but progress is somehow slow.”
The problem here is not “the fact that things are not moving forward” itself, but “the fact that we cannot see why they are not moving forward.” If you cannot see it, neither dialogue nor improvement can begin.
In other words, the first step to improving a development team’s performance is “visualization.”
- How much time is each type of work taking?
- Where is waiting occurring?
- Who is bearing a concentrated load?
- Where are there movements that the team could potentially improve?
Enabling these questions to be answered based on facts rather than feelings—
that is the role of “visualizing development productivity.”
Visualization is not something used to “evaluate” teams or engineers.
On the contrary, it serves as a “trigger for dialogue” that allows worries and difficulties that someone had been carrying alone to be shared across the team and collaboratively improved.
We shine a light on this “hard-to-see domain” and support teams in moving into a state where improvement is possible. Connecting dialogue between management and the field, and helping create an environment where teams can grow on their own—this is the starting point of the “development productivity visualization support service” we provide.
Five concrete benefits you gain from visualization
Even if the awareness that “visualization is necessary” is shared, what exactly do you gain by visualizing?
Here we explain the main benefits of visualization from five perspectives.
1. It reveals bottlenecks and becomes a starting point for improvement
There are many steps in the development process. Requirements definition, design, implementation, review, testing, release—if any of these takes a long time, it affects overall progress.
Visualization makes the time spent in each phase and the points of stagnation “visible,” clarifying where there is room for improvement.
Example: It takes an average of 48 hours before Pull Request reviews start → The review structure needs to be reconsidered.
2. It clarifies team workload and imbalance, enabling support for sustainable work styles
Visualization allows you to obtain numerical information such as “who is handling how many tasks” and “which areas they are focused on.”
This makes it possible to detect early whether a particular member is overburdened or whether excessive multitasking is occurring.
3. It reduces mismatched perceptions and fosters constructive dialogue
Expressions like “busy,” “blocked,” and “delayed” are perceived differently depending on one’s role and viewpoint.
Visualized data serves as a “common language” that is not swayed by subjectivity, promoting dialogue within the team and reducing misunderstandings and blame-shifting.
4. It enables measurement of the effects of initiatives
The purpose of improvement initiatives is not to implement them, but to see “whether things improved.”
With visualized metrics, you can verify effects in forms such as “average PR lead time has been reduced by two days compared to before the initiative” or “the bug-fix ratio has decreased by 20%,” which makes it easier to sustain efforts.
5. It becomes material for dialogue with management and communicates the value of the development organization
Because the work of engineers is hard to see, it tends to be underestimated.
However, visualization makes it possible to present facts as graphs and metrics, such as “how many features are being delivered at what speed” and “to what extent quality is being maintained.”
This becomes a very powerful tool for CTOs and VPoEs when explaining the results of development investment to management.
Visualization is not an initiative for “collecting numbers” alone.
It provides “material for moving forward” in all aspects: on-site improvement, team health, and dialogue with management.
We support the end-to-end flow of introducing such visualization mechanisms, embedding them, and leveraging them for improvement.
What data should you collect to visualize development productivity?
Even if you share the understanding that “visualization is important,” a common stumbling block is the question: “So what exactly should we visualize, and how?”
On the ground there are complex codebases and piles of tasks—how should we slice them so that the overall picture of productivity becomes visible?
In this chapter, we introduce the data that actually becomes the target of visualization, categorized “by purpose.”
1. Data for understanding bottlenecks
To identify where “blockages” are occurring in the development process, the following data is useful:
- Pull Request lead time (average time from PR creation to merge)
- Time until review starts (from PR creation to first review)
- Ticket waiting time (time spent in statuses such as “Waiting for Review” or “Waiting for QA”)
- Lead time until task completion
By tracking these, you can see which steps are stopping the flow of development and where time is being wasted.
2. Data for measuring the health of work styles
To determine “sustainability of work styles” and “excessive load imbalance,” the following information is important:
- Number of WIP (Work In Progress) items (number of tasks being handled simultaneously)
- Imbalance in review assignments (whether they are concentrated on specific members)
- Commit frequency and time of day (whether extreme late-night work is continuing)
- Number of handled items per team (resource distribution by department or group)
These serve as early warning signs for risks such as “overwork” and “over-dependence on individuals.”
3. Data for maintaining quality and a healthy development balance
To judge whether you are “rushing ahead with only feature additions” and “neglecting refactoring and quality improvements,” the following perspectives are effective:
- Ratio of bug fixes vs. new feature development
- Trend in the number of issues related to technical debt
- Test execution time and success rate (CI/CD logs)
- Trend in release frequency and lead time
Rather than looking only at speed, it is also important to consider whether there is “the ability to maintain” and “a structure that allows you to roll back.”
4. Data that indicates team collaboration and information sharing
- Frequency of document updates (Notion, Confluence, etc.)
- Activity level of technical discussions on Slack or chat
- Number of comments and review rounds in code reviews
These are somewhat difficult to measure quantitatively, but they serve as references for gauging whether “knowledge is being shared” and “tacit knowledge is not overly tied to individuals.”
Note: The goal is not “collecting data” but “putting it to use”
Much of the data listed here can be obtained from tools you already use daily, such as GitHub, GitLab, Jira, Notion, and CI tools.
What matters is not “forcing the introduction of new tools,” but the perspective of “how to organize and interpret the information you already have.”
How to interpret metrics: perspectives for identifying “good states” and “warning signs”
In the previous chapter, we introduced the data you should collect to visualize development productivity.
However, simply collecting data is not enough. What matters is correctly interpreting “what state you are in” from that data.
In this chapter, we explain the key points for distinguishing “good states / warning signs” for representative metrics.
1. Pull Request (PR) lead time
- Good state: From creation to merge is within 24 hours, and reviews start on the same day
- Warning signs: It takes 2–3 days or more before reviews start / 5 days or more until merge
There may be bottlenecks in the review structure or decision-making process.
It is also possible that PRs are too large in scope, making it hard for reviewers to tackle them.
2. Time until review starts
- Good state: Reviews start on the same day or the next day after PR creation
- Warning signs: Some PRs are left unreviewed for several days
Issues may include low review priority or over-dependence on specific individuals causing reviews to stall.
3. Ticket lead time and waiting time
- Good state: Tickets are completed in about 3–5 days / status transitions are smooth
- Warning signs: Some tickets remain in “Waiting for Review” or “Waiting for QA” for more than a week
Possible causes include poor task granularity or prioritization, or review capacity being overly concentrated.
4. WIP count (number of concurrent tasks)
- Good state: Focus is on 1–2 tasks at a time
- Warning signs: Handling 5 or more tasks simultaneously / number of completed tasks is not increasing
When there are too many parallel tasks, focus is scattered and “work that never reaches completion” tends to increase.
5. Number of review comments
- Good state: There are about 2–5 constructive comments, with appropriate feedback and suggestions
- Warning signs: Zero comments / conversely, 20 or more comments
Too few comments may indicate that reviews are merely formalities, while too many may suggest unrefined specifications or misaligned understanding.
6. Commit frequency and activity patterns
- Good state: Stable, almost daily commits and continuous activity
- Warning signs: No activity at all for several days / activity heavily skewed to late nights or holidays
This metric helps you avoid missing signs of stagnation, over-concentration, or fatigue.
7. Ratio of bug fixes vs. new feature development
- Good state: New feature development is the main activity, with bug fixes kept to the necessary minimum
- Warning signs: Bug fixes account for the majority / frequent specification rework
There may be issues in quality control, testing, or alignment in design and requirements definition.
8. Imbalance in reviews (over-dependence on individuals)
- Good state: Reviews are distributed among multiple people and not overly dependent on individuals
- Warning signs: The same person is always doing the reviews
This easily becomes a bottleneck and leads to stagnation when that person is unavailable, as well as to knowledge being overly tied to individuals.
9. CI/CD time (build and test)
- Good state: Completed within a few minutes, not disrupting development tempo
- Warning signs: Takes more than 10 minutes / frequent failures
Slow feedback loops for developers increase the time required for trial and error and rework.
10. Qualitative feedback (retrospectives and 1-on-1s)
- Good state: Comments such as “It’s become easier to work” or “Things are smoother than before”
- Warning signs: Vague complaints such as “I don’t know what’s going on” or “It’s hard to move forward”
Hints for the next improvement points often lie in experiences that cannot be fully captured by numbers.
The key to interpretation is not “finding anomalies” but “capturing signs”
Visualized numbers are not necessarily for finding “abnormal values” or “mistakes.”
What is more important is noticing “signs” in everyday work and using them as triggers for dialogue and action.
Where to start and how to expand: thinking about priorities and introduction phases
Even if you understand the importance of metrics, it is not easy to immediately answer questions like “Which should we visualize first?” and “What introduction steps fit our team’s current situation?”
If you try to do visualization all at once, it becomes a burden on the field and will not stick. That is why it is important to proceed step by step, in a meaningful order.
Two axes for introduction
We organize the priority of introducing visualization along the following two axes:
- Ease of collection: Can it be easily obtained from existing tools?
- Improvement impact: How much will the information affect team improvement?
We recommend dividing the steps as follows and proceeding along these two axes.
📘 Step 1: “First step of visualization” that is easy to collect and immediately effective
Start by visualizing “where things are getting stuck” and generating on-site dialogue.
| Metric | Reasons and usage points |
|---|---|
| PR lead time (time from creation to merge) |
A powerful metric for measuring the most frequent “flow of development.” Can be automatically aggregated via GitHub/GitLab APIs or Insight features. If integrated with CI/CD, deployment time can also be included. |
| Time until review starts | A key metric for visualizing whether there is stagnation due to waiting for reviews. Can be obtained via GitHub Events API or tools like Swarmia and Haystack. Can also be combined with Slack notifications. |
| Ticket completion lead time (from issue creation to completion) |
Optimal for measuring task design and process smoothness. Easily obtained from Jira, Linear, Notion, etc. Aggregation via CSV export is also realistic. |
📗 Step 2: Division of work and flow—phase for organizing how the team operates
| Metric | Reasons and usage points |
|---|---|
| WIP count (number of tasks in progress) | Too much WIP tends to increase “work that never gets finished.” Can be aggregated from “In Progress” tickets in Jira or Linear. Board views also help manage this visually. |
| Imbalance in reviews (over-dependence on individuals) | Effective for visualizing concentrated load and over-dependence on specific members. Review history can be obtained via GitHub APIs. Tools like Swarmia can visualize it. |
| Number of review comments | A metric for measuring review quality and the presence of misaligned understanding. Analyze the number of comments and review rounds on GitHub Pull Requests. |
📙 Step 3: Quality and rhythm—phase for balancing speed and sustainability
| Metric | Reasons and usage points |
|---|---|
| Ratio of bug fixes vs. new feature development | Shows signs of quality management issues and accumulation of technical debt. Can be aggregated by categorizing ticket types or PR titles. |
| CI/CD time (build and test duration) |
Measures development tempo and the health of feedback loops. Can be obtained from execution logs of GitHub Actions, CircleCI, Jenkins, etc. |
| Commit frequency and activity patterns | Reads fatigue or stagnation from extreme skews or silence. Analyze by time and count using Git logs or GitHub Insights. |
📕 Step 4: Discomfort and atmosphere—phase for not missing qualitative signs
| Metric | Reasons and usage points |
|---|---|
| Voices from retrospectives and 1-on-1s | A valuable opportunity to capture “difficulty” and “anxiety” that are not quantified. Use regular retrospectives, 1-on-1 notes, and anonymous surveys. |
| Team surveys (visualizing satisfaction and anxiety) |
Provides hints that encourage self-directed improvement actions. Easy to introduce via Slack polls or Google Forms, suitable for regular monitoring. |
| Presence of knowledge sharing (document update frequency) | Indicates signs of information over-dependence on individuals and high learning costs. Analyze update histories in Notion or Confluence, or README change histories. |
🎯 “Phase-based checklist” for assessing team status
| Phase | Checklist items | Criteria for starting |
|---|---|---|
| 📘Step1 | - You don’t know where PRs or tasks are getting stuck - The team says “we’re busy,” but progress is not visible - Managers cannot fully grasp the flow on the ground |
✅ A situation where you should start from this step as the starting point of visualization |
| 📗Step2 | - Reviews are concentrated on specific people - Too many parallel tasks, and completions are not catching up - Reviews feel like they are just “rubber-stamping” |
✅ A phase to focus on structural issues in workload, imbalance, and work styles |
| 📙Step3 | - Many bugs and repeated post-release issues - Tests and CI are taking a long time - Development rhythm cannot be maintained and stagnation is visible |
✅ A phase to address emerging issues in quality and sustainability |
| 📕Step4 | - “Difficulty in moving forward” remains unarticulated in retros or 1-on-1s - Little information sharing and noticeable knowledge imbalance - Onboarding of juniors and mid-career hires takes a long time |
✅ A phase to visualize the “quality of atmosphere” that does not appear in numbers |
In every step, the key is not to “do everything at once,” but to start small with what fits your current situation and grow it larger. We work with you to design and execute each step.
About our “Development Productivity Visualization Support Service”
If you have read this far, you likely now have a clearer idea of “why visualization is necessary,” “what to visualize,” and “in what order to introduce it.” So how do we support this effort? In this final chapter, we introduce the content of our support service.
Structure of the support we provide
| Phase | Support content provided | Purpose of support |
|---|---|---|
| Diagnosis phase | - Review of current tools and data structures - Interviews on team composition and development flow - Co-design of target metrics for visualization |
Building the foundation for organizing “what to visualize and in what order” |
| Visualization phase | - Support for defining metrics and data collection - Building scripts for automatic data collection - Designing dashboards (Looker Studio / Notion, etc.) |
Building a state where things are actually “visible” and can be used in daily work |
| Interpretation support phase | - Creating guides on how to interpret numbers - Participating in weekly reports or regular meetings - Organizing interpretations and insights for each team |
Creating starting points for dialogue and improvement from visualized data |
| Improvement support phase | - Proposing and designing improvement initiatives - Defining metrics for effect measurement and observing changes - Supporting internal rollout to embed practices |
Transitioning to a team that can continuously run improvement cycles |
How we proceed with support
-
Hearing (free)
- We listen to your current sense of issues, tools in use, team size, etc., and propose a first step for visualization.
-
Initial diagnosis & visualization prototype
- Instead of building everything at once, we construct an MVP (minimum viable visualization) focused on key metrics.
-
Ongoing interpretation and improvement support
- We help set up forums where the team interprets visualized numbers together and supports operations that lead to action.
Flexible introduction formats
- Can be introduced on a per-team basis (e.g., starting with one team within the development department)
- Visualization design tailored to tools you already use (Jira / GitHub / Notion / CI/CD tools, etc.)
- Support for embedding visualization as a culture (we also prepare guides for training, rollout, and retrospectives)
✅ Goal: A self-driving team where dialogue begins
Our goal is not “to organize metrics” or “to achieve high scores.”
Through visualization, we aim to create a state where:
- “Why are we getting stuck?”
- “How can we make things better?”
are naturally discussed within the team, and where numbers are used not as “evaluation” but as “material for dialogue.”
We hope to work with you from that very first step to spark this culture.
Related Articles
Complete Guide to Web Accessibility: From Automated Testing with Lighthouse / axe and Defining WCAG Criteria to Keyboard Operation and Screen Reader Support
2023/11/21
Introduction to Automating Development Work: A Complete Guide to ETL (Python), Bots (Slack/Discord), CI/CD (GitHub Actions), and Monitoring (Sentry/Datadog)
2024/02/12CI/CD Strategies to Accelerate and Automate Your Development Flow: Leveraging Caching, Parallel Execution, and AI Reviews
2024/03/12Strengthening Dependency Security: Best Practices for Vulnerability Scanning, Automatic Updates, and OSS License Management
2024/01/29Bringing a Go + Gin App Up to Production Quality: From Configuration and Structure to CI
2023/12/06