This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...
Pinpoint started as a result of founders Jeff Haynie and Nolan Wright’s frustration with their lack of insight into the work of their engineering teams — even as engineers themselves. So naturally, we were eager to start using Pinpoint ourselves as soon as the product was available and served as the first beta customer. We have a strongly held belief that if the product can’t work for us, it won’t work for our customers.
As Vice President of Customer Success, I talk to a lot of our customers and have seen the transformation that Pinpoint brings to their engineering organizations. Just like I do with all our customers, I meet with our internal users at Pinpoint on a regular basis to learn what goals they have for their teams and to get feedback on their experience using Pinpoint. With almost a full year of using Pinpoint ourselves, I wanted to stop and reflect on what impact it has had on how we built the product in 2019. I sat down with Scott Davenport, Vice President of Operations and Rick Blalock, Director of Engineering, to see how Pinpoint has improved our engineers visibility into how well they are working, what work needs attention, and some areas of improvement into our own process.
(Note: Because we believe in full transparency, any screenshots you see are of our own data)
Scott: I would try to cobble together a picture of what was going on by using a combination of Jira Dashboards, using JQL to try to group things in a logical way. I’d also occasionally hop over to GitHub to try and make sense of activity feeds, repo by repo. I’d speak with my managers constantly to get their statuses and updates on progress throughout the day in a number of different tools.
Rick: I started my day by going to Jira to check progress on our sprint board. Then I’d look at the organization’s GitHub repo list and click on each repository, look at all the pull requests and the commits and checking to see what code was done and which pull requests were still pending. It was generally effective, but it was also time consuming. And I missed things frequently.
Scott: I use Pinpoint to see how teams are making progress on sprints, what issues need attention and to see how the team activity is progressing when it comes to delivering code. The most applicable screens for me are the Pinpoint project dashboard and metrics. I need to understand the flow of activity and how we are working.
I tend to dive pretty deep into the details on how individuals and teams are performing, but I’m most excited about individuals having the ability to see this information for themselves in order to understand their own impact on the team and be more productive. I spend a lot of time reminding people to follow best practices, but I think that most people don’t realize when they’ve deviated from the best practice. Now that individual engineers can easily take a step back and see when they have departed from best practices, they can self-correct. I won’t even have to intervene.
Rick: I’m not jumping around between different systems to piece together what is going on with the team as much now. I use the Pinpoint dashboard instead of combing through repos in GitHub. I often look at the dashboards for teams and individual developers to see what teams and team members are spending their time doing to determine what is blocking them.
Scott: At the moment, no. That said it certainly provides information in a unique way to give me insights into the team and individual activities. Having a way to measure the team is really important for us internally so that we can identify areas for improvement and most importantly to catch people doing the right things. In 2020, we have a goal to start using the metrics to inform us of how individuals and teams are using their time and what practices result in the highest functioning teams and people.
Rick: I use Pinpoint’s dashboards to prepare for one-on-ones, but it’s just one piece of a larger puzzle. It’s a powerful tool to start the conversation and uncover specific areas where individuals might need coaching. I want to be thoughtful on how I talk about data when it comes to individual performance, and make sure that any conversations around it are helpful. I also think it’s important to note that although it sounds scary to look at these hard numbers, we’ve seen examples of Pinpoint uncovering really exceptional performance from an engineer that the company leadership had been unaware of before they began using Pinpoint. So using the metrics to not only highlight areas of improvement, but also achievements and contributions to the team in an effort to support their personal goals is important as well.
Scott: For us as a team, I’d like to get better at estimating how long things will take. I’d also like to make sure we’re tracking our performance over time and working towards continual improvement in very specific areas like cycle time, throughput and removing code review bottlenecks. I want to narrow the surface area of systems my teams have to interact with thereby reducing the overhead of needing to switch context constantly from Jira to GitHub, back to Jira, to deployment systems, meetings, back to Jira etc. Then finding a little time to actually write code among all those distractions.
Rick: Thinking about Pinpoint’s product, I think there’s huge potential for using Pinpoint to improve alignment between the engineering organization and the business leadership goals. However, to make that happen we need to improve the context provided in each dashboard for the people doing the work, so that people outside of engineering can more easily understand how the engineering metrics are relevant to the business. I’d like to see Pinpoint be used to ensure engineering teams are spending their time on high-priority projects — in other words, to make sure engineering teams and business teams agree on what the high-priority projects are.
Vice President, Client Success & Support