What Makes An Engineering Team High-Performing? An Interview with Deane Smith

Written by: Kara Phelps
5 min read
Stay connected

Deane Smith is the senior engineer manager in product research and development at CloudBees. We spoke with Deane to learn about how he manages and measures a high-performing team of eight software engineers around the globe. CloudBees Engineering Efficiency is one of his secret weapons when it comes to visibility into his team’s work. We asked him to share how it’s helped his team avoid distractions and focus on what matters most.

What does it mean to be a high-performing team?

For me, it means that we have data to support the perception that we are high-performing. The ability to ensure customer satisfaction is number one, and with Net Promoter Score (NPS), you have quantitative data. If a team has a high customer satisfaction score, you can probably assume they're a high-performing team. 

Everything else feeds into customer satisfaction. Improving mean time to restore helps customer satisfaction—and so does the ability to add new features that the customer perceives as being valuable in a reasonable amount of time. To me, all of these things together constitute a high-performing team. Of course, some teams don't deliver anything to external customers, so their customers are internal people—but I think you can use some of the same measures.

Also, knowing that you have people on your team who are there for unplanned work is huge. In a high-performing team, you need a protocol where you recognize that unplanned work will always be there. There's nothing we can do about it; it's more about how we handle it.

When you talk to product stakeholders, what are the key questions you want to make sure you can answer?

People want to know, with a certain level of accuracy, when we're going to deliver something. CloudBees Engineering Efficiency can help me measure the velocity of a team. It's an additional way to look for similar projects of similar size and scope, or similar features or bugs and so on. I can look at what it took, not just to commit a fix, but to see it all the way through until it gets deployed.

How do you get a team to improve? What metrics do you use to make sure that you're there?

Hope [laughs]. Time to restore is important. Let’s talk about this in terms of Jira priority levels. We can turn around anything labeled “critical” fast. We need to be predictable to give the stakeholders what they’re looking for. That’s one thing.

Customer satisfaction is another, although no one is coming in and saying, “Hey, get your NPS score up.” It's just that if we didn't, we'd be foolish. To have a measure of customer satisfaction, which would be NPS from my perspective—I don't think there's any other better way to see how well your team is doing. You need to be dialed into that at all times. You tweak things to see if your NPS gets better.

Of course, the same goes for people who are answering customer support problems. It's a holistic thing, but the product NPS should reflect upon ourselves as engineers.

How does CloudBees Engineering Efficiency help the team measure and improve?

Right now I'm using CloudBees Engineering Efficiency to find my stale PRs. There's nothing else, as far as I'm aware, that lets you pull unplanned repositories and relate them to Jira projects and thus back to something bigger. In my team, I have two projects that are in CloudBees Engineering Efficiency, and I use them for stale PRs quite rigorously. We can focus on what matters, and why is this thing here? CloudBees Engineering Efficiency helps me better understand what I inherited and how to get a grip on it. And by “grip,” I mean to simplify or get rid of things that don't matter. An aging Jira ticket that somebody entered two years ago, four years ago—I'm really curious to see what that is and why it's here. And I want to delete it. I only want a backlog of stuff that matters. Clearing out stale PRs and Jira tickets prevents distractions for the team.

And as I look at some of the data and insights, there are some handy charts and graphs where I can go back and look at data points like when I joined the team. We formed this team back in January, and there were some people working on the same project before that. Have I made things better?

I’m also looking at trends. We're doing Kanban—is that working? Are people entering more issues? Do the issues getting entered have more breadth and depth? Are we responding to issues in a timely fashion? For me, it always comes back to the mean time to restore for those issues labeled “critical” and “high.” Are we using the priority field correctly? 

I want to know, using the component field in Jira and using labels, where I need to invest in the future the most, based on our backlog. So Jira helps there, but CloudBees Engineering Efficiency tells you your average PR size for this particular project. It tells you that this component has this many files and has this level of complexity from this user. It tells you how long it takes to get the PR through. I can look at this information and ask somebody on the team, “Is there a way to break this up?” I prefer a more iterative approach and CloudBees Engineering Efficiency helps me because I can see both the Jira project and the PR together in one place.

Basically, I use CloudBees Engineering Efficiency to make sure I'm helping the team. I'm not going to tell principal engineers what to do. I'm just going to suggest, then present data and say, “How can we fix this?” It’s hard to argue with data. I really want us to be a high-performing team, and CloudBees Engineering Efficiency helps us get there. 

Learn more about how CloudBees Engineering Efficiency can unlock engineering productivity, help your team focus and improve software delivery speed and predictability.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.

Loading form...
Your ad blocker may be blocking functionality on this page. Please disable for an improved experience.