The data engineering leaders need

*Answers have been edited for length and clarity*

What data points and metrics do you think development managers should be paying attention to?

Of course managers are often collecting and tracking their own metrics, and it can be hard to sort through it all and determine which metrics provide really meaningful and actionable insights. These data points are incredibly important, but I want to start by focusing on some soft skills. Managers need to be mindful of overall wellbeing as well as employee happiness and contentment at work. Developer satisfaction metrics are something we're seeing written about a lot these days.

The last several years have made everyone much more aware of how things happening outside of work impact our overall wellbeing and our ability to focus on work and perform to our utmost potential. Being able to be open and honest with my managers when my life outside of work is creating challenges has been really comforting but also as a manager myself, when my team has stuff going on outside of work, it helps me empathize and contextualize the occasional dip in performance.

I love that you started off with overall wellbeing and happiness at work, because there's so much data that shows if people are happy it is beneficial to them and the organization alike. If they have a good sense of self-worth, they feel like they're connected to the company and the projects that their team is working on, they're going to be more productive.

Absolutely. You're absolutely right. Mid-level managers may have relatively little control over things like benefits packages or PTO policies, and even salaries to some extent, but we do have control over things that can make our people's jobs enjoyable. Are they occupying roles on the team that they wanna be occupying? Are they being given time to learn and to upskill?

Those things have absolutely contributed to my happiness at work. We can control whether our teams are overworked or even underworked. Really good engineers will tell you that they’re not happy when they're sitting around twiddling their thumbs.

Managers need to be collecting and paying attention to data that provides insight into that dev satisfaction piece, and part of that data is qualitative. Part of that data is quantitative as well, and people are getting really creative with data-gathering methods these days. We're starting to see a lot of products, like Pluralsight Flow, that provide that data gathering.

Speaking of Pluralsight Flow, can you share some of your personal favorite reporting options in the tool and how you use them?

I love the Delivery Module report. It’s instrumental in helping teams determine what parts of their process are working really well and what processes aren’t. It’s great for improving efficiency across the board. Ticket Log has really been one of my go-to reports as a leader. I've gotten in the habit of looking at it first thing in the morning just to see the state of our work as we head into a new work day.

As teams progress further toward the end of a sprint, there are a great deal of filtering capabilities in the ticket log. I can limit the set of tickets by assignee if I'm interested in seeing what they’re working on for the day or week. I can see if they’re waiting for somebody else on a ticket. What are the blockers? I can toggle between a list of what's already been completed in a sprint and what hasn't even been started yet, which is a high level of information to have on hand. 

It also shows easily what tickets have had a lot of activity on them, including new comments, description changes and any backward movement in the pipeline. With that data, I can just easily see which engineers I need to check in with, who might need assistance, and I can determine how I can make their job easier that day.

These tools also create great collaboration opportunities, especially on remote teams. Seeing where comments and conversations are taking place within a ticket lets leaders see who is working together and connecting.

To your point, if a ticket has a ton of comments unfolding on it, that's not necessarily a bad thing. Sometimes that's a really good thing. It means we're communicating well as a team. It makes it so that, as a product owner, I don't have to tap your shoulder and interrupt your workflow and ask you for an update. And as an engineering leader, I don't have to shoot you a slack message asking for the progress report. It's all there in the ticket.

Can you touch on another report you use frequently in Flow?

The Retrospective report is one we use all the time. It’s great because it aggregates the metrics that show up in the ticket log at that individual ticket level. So, you know, with these aggregates, we can dig into the data and start to formulate and test theories around what's working well in our process. What's propelling us toward delivering to customers? And then, on the flip side, what's impeding our delivery? 

It's really, really important to do that as software developers when you're shipping code and your goal is to deliver value to customers. We all need to be on the same page about what actually constitutes “done.” Some engineers on our team thought once their code was merged into our staging environment, it was out of their hands. They were done and onto the next ticket while others thought, no, you shouldn't move on to the next ticket until that work is promoted to production where the customer can actually use it. It would've taken us a little bit longer to understand that if we hadn't talked about it in our retros. 

I love the idea of these connection points because, with us all being remote, if you're never interacting with other people at all, and you're just working on the same thing over and over, it can become isolating. It’s like The Shining. “All work and no play.”

Absolutely. These touchpoints and comments can remove that isolation. It helps you feel like you’re part of the team. And then your wins are not just individual wins, they’re team wins. When we're all collaborating on the same thing we just have more opportunities to learn from each other and we waste less time on code reviews or projects that we don't really know that much about. The overall quality of the work that we do goes up and so does the developer satisfaction.

Normally I ask about the best advice ever received by our podcast guests, but you wanted to mention a really interesting piece of bad advice!

I had so much fun reflecting on this. The worst advice I've ever gotten in my life is this whole fake it ‘till you make it thing. Right? I just don't understand how that works from a practical perspective in your profession. And I really don't understand how that makes you a good employee and a good teammate. 

If you don't have certain skills or abilities yet, you should be honest with yourself about that. And you should be honest with your manager so that the two of you can work together to find ways for you to acquire those skills and abilities. And then the confidence follows, right? Because not only do you now have those skills and abilities, but you've got the satisfaction in knowing you’ve learned something new.

Yes, you put yourself in a vulnerable position by raising your hand and saying, “Hey, I actually don't know what that means.” But none of our managers believes or expects us to have all of the knowledge and all of the skills to be totally effective at our jobs. They know that we have to learn and grow towards that. 

Not knowing something is okay. Admitting what you don’t know provides not only a learning opportunity but it also builds out even more collaboration and mentoring opportunities. Being open to admitting what you don’t know can actually help drive a better team culture. It’s all connected back to these reports. When we’re able to see what we know and what we’re doing, we can all work more efficiently and be better connected.