Engineering Leadership Summit: Roger Deetz, VP of Technology at Springbuk

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Roger Deetz, VP of Technology at Springbuk. He discussed the role of a leader in fostering company culture, and his strategies for using engineering metrics to encourage healthy coding habits at scale. Below is an excerpt from the fireside chat portion of Roger’s session, edited for length and clarity. 

Hillary Nussbaum, Content Marketing Manager, Code Climate: I’ll let you get started, Roger. Can you introduce yourself and tell us a little bit about your role at Springbuk?

Roger Deetz, VP of Technology at Springbuk: I lead the Technology Team at Springbuk. For us, that includes our Software Engineering teams, our Software QA teams, and our Infrastructure Group, which includes DevOps, Security, and our one-person IT organization, as well as our Data Quality team.

Springbuk does health analytics and health intelligence. We deal with tons of healthcare data. The quality of that data is critical to our customers, so we’ve got a group of folks, data analysts, who work on that. Those are all part of the Springbuk technology team.

Tell us a little bit about your particular role as VP of Technology, and how you got there. 

In the day-to-day at Springbuk, we are building a platform, executing products and features. So I am partnering a lot with product, partnering with sales, partnering with our support and services team — who are ultimately servicing the product when a customer is using it — and balancing the needs of engineering execution with managing the costs of our infrastructure and the quality of our data.

I’m just representing the technology, as a whole. At Springbuk, we really think that we have an important mission, a mission that someday we can prevent disease with data. That requires good data, requires good technology. We’re all rallied around that cause.

In terms of my background and how I got there, I started as an engineer. I spent the beginning of my career writing code and bouncing a little bit back and forth between being an engineer and being more of a UX person. I moved to a few different companies. I had a chance to work on some more sophisticated, architecture-type projects, where I was designing a framework, and setting up the patterns that were going to be used across the product, across the enterprise.

That was when I started to get a little bit of team leadership skills. It was informally, and people weren’t reporting to me, but I was responsible for leading initiatives. I probably should say, I was a very reluctant manager. I viewed myself as the technical person, and I remember experiences with managers where I didn’t know what they did, and I didn’t know why we had managers.

I was reluctant to officially move into a management position. Then I realized that it was my path, and it was my calling, and there is a real craft to it. One of my first main management roles, I took on at a company called Angie’s List, which is based here in Indianapolis, and I was part of leading the engineering team there.

And then, I met some of the Springbuk folks at a community networking event. They were pitching the Springbuk product and platform, and they were getting ready to scale up their company and their engineering org, and I really enjoyed the challenge of being part of a growing team, and being part of a company that was looking to scale. I built a relationship with some of the folks there, and then I eventually joined, and I have been very excited and very proud to be part of that period of Springbuk’s growth.

Just to get us oriented a little bit, do you happen to remember how big the engineering team was when you started? And where are you at now?

When I joined, I was brought in as the leader of just the engineering group. I feel like it was about 10 folks at the time. We had two small delivery teams that were part of the engineering group. And then, as with any scale up, it was always lots of growth and change. We’re now at basically five delivery teams, and then some of those other technical functions, like infrastructure, came into my group over a period of time.

We’ve got a little more than 30 folks in tech right now. Springbuk, as a whole, has a little more than 100 people.

And what is it like to work at Springbuk? Can you tell us a little bit about the company culture?

Culture has been a really important part of Springbuk from the beginning. Our co-founders, Rod and Phil, were very intentional in knowing that culture would be important, and knowing that it needed to be rooted in the company from the beginning. They put a really big emphasis on that.

I don’t know if this is the dictionary definition or not, but I think about culture as the expression of the values of a group of people. Those values are the shared beliefs of those people.

At Springbuk, there are three core values that we talk about all the time, and they’re really important to us. They go by the short names of Win Together, Raise the Bar, and Never Settle. I think Win Together is pretty self-explanatory, because you want folks to cooperate on a common goal. Raise the Bar is all about leveling up and going to the next step, whether it’s as a company or as individuals. And then, Never Settle is really more focused on the individual. We want all individuals to pursue their own growth paths, and Springbuk wants to support them on their growth path. 

We take those values pretty seriously. We fold them into our job descriptions, and our onboarding, and a lot of other materials. We talk about them all the time. You hear it in the language of the company, “Hey, this is a real Win Together moment,” or, “you really raised the bar there.” I think when you hear people just naturally say that as they’re talking, that’s a good indicator that the culture is woven in.

It does sound like it’s really persistent throughout the company. What do you think is your role as a leader, in terms of encouraging that, and cultivating and maintaining the company culture?

That’s a big question, I love it. I love a big question. I was thinking about this quite a bit earlier. If you think about the culture as the expression of values, the values are that social contract that everybody in a group has. We all believe in these same things, and we agree that we’re going to behave in this way. I know I’m going to behave this way, and I expect you to behave that way. That forms the social contract of a group.

Those expectations have to be there before any kind of trust can be built. And then, I think it’s fairly well-known that trust is then the foundation of everything else. Cooperation, and psychological safety, and mutual respect can only be there if there’s trust. Trust really comes from those shared values and those shared expectations.

That could apply to anything; a team, a company, a family, a whole nation. And so, as a leader, I really think the role is to foster an environment where that social contract is upheld and everyone knows that it’s going to be upheld. There’s a million things that then go into that — modeling your own behavior, coaching folks, all that sort of thing. Easier said than done, maybe.

As a leader, you’re accountable for what happens, even if you didn’t do it. That’s the essence of leadership. No individual can scale, so how can you get a group of folks to do something together, when you, yourself, can’t do it? The only way that happens is if people have the expectation that everybody else is going to uphold the contract. Right? They can’t be wasting any mental energy on, “What does this person believe?” or, “How are they going to behave in this situation?”

You have to set the tone that everyone just knows how it’s going to be, so then all your mental energy can be spent on doing the work together. As a leader, it all just comes back to making sure that the environment upholds the values of your organization.

It’s interesting that you said that Springbuk’s mission is to prevent disease with data, because I know you also have a data-driven approach to leadership, and a way to use metrics to help cultivate company culture. Can you tell us a little bit about that, and how that works?

Yeah. I also should probably confess that I’ve been leading engineering teams for a while, and have long been a skeptic when it comes to engineering metrics. I think many of us have had the trauma of a non-technical stakeholder or boss who doesn’t get it, and is looking for that one magic thing. We know that people in general and engineers specifically, we can really over-optimize for something. You say you’re looking for one thing, and they will make that one thing happen, even if it’s not aligned with the best outcome. 

I’ve been part of high-performing teams and part of low-performing teams, and I spent a lot of time thinking — what are the habits of those teams and of those engineers that actually demonstrated that they were high-performing? We in the tech leadership team at Springbuk, we’ve thought about that. What are the habits we see, and then what are the data that might support those habits?

Making small changes, frequent commits, pushing regularly, small pull requests, prompt code reviews. All those things are good habits because they lead to small changes that are easy to review, easy to test, easy to get out the door.

And so then, we thought, that’s the kind of engineering behavior we want — lots of little small things going out quickly that we have high confidence in — what’s some of the data that would reveal that? We chose some metrics around Coding Days, which essentially is, “Are you pushing stuff every day? Are you making small commits?” Things around review time, and how quickly we’re getting to reviews, which is a function of how big the code change is. Things about throughput, like Number of PRs Merged, which is a lagging indicator — if all the changes are small, and if things are being quickly reviewed, then more code’s going to go through.

And then, of course, we have a whole other set of metrics around the actual performance of the app, like Page Load Time, and Uptime, and Data Quality, and all that other stuff. Those are more outcome-based. When it came to the engineering behavior, we started with those and used those to steer the ship.

How did the initial introduction of those metrics happen?  

We, from the very beginning, felt like we needed to be very transparent about it all. We didn’t want to have secret metrics that the managers knew about, that no one else knew we were watching. We did an intentional rollout with the whole team, to say “Hey, this is the stuff that we’re looking at, and this is why.”

We’ve adjusted that over time. I usually do a yearly kick-off with the team, and we look at some of the metrics from last year, and we talk about what we’re going to be looking at this year. We have that documented in some of our internal materials, and we cover that during onboarding. All of our engineers have access to the stuff that we use to look at those metrics — our dashboards, and the Velocity product.

One thing I think is really important is that we do take the metrics seriously, and we look at them, but we also realize that they’re just … They’re conversation starters. The outcomes are, are customers happy? And are we working towards our mission? 

That makes total sense. We often talk about how it’s important to be transparent with your team and create that, as you mentioned before, that culture and foundation of trust. That’s really important.

Can you tell us a little bit about how you’ve changed which metrics you look at over time? You mentioned that you talk about that every year. Are there any that you’ve stopped tracking or started tracking, based on those conversations?

Yeah. We started very simple. We started with just Coding Days as our metric. That was, again, seeking to measure that healthy habit of, “Are you making small commits and pushing them frequently?” And then, over time, we expanded and we included Percent of Sprint Complete.

I’ve had this conversation a handful of times in my career, where people, particularly folks that aren’t familiar with agile practices, will be like, “How many story points can you do? Why is this team not doing 35 story points, when this other team is? What’s better?” You can’t compare, because story points are relative. 

We did want to have some measurement around what I would consider to be the healthy habit of, “Can you accurately forecast what you can do, and then can you rally to complete that thing?”

We started to track our Percent of Sprint Complete, which is basically, when you planned the sprint, how many points did you and the team think that you could do, and then how many of those did you finish when the sprint was over?

We target 80%, because we know it’s not an exact science, and it’s not something we’re trying to be punitive about. It’s just that as professional, skilled engineers, you should have a pretty good idea of how much you can do in a sprint, and you should be able to accurately forecast that. And then when your team is working, you should rally around to finish what you said you would do.

So we introduced that one to keep an eye on how well we were forecasting and how well we were completing. And then, over time, we added things like Time to Review and PRs Merged. We’ve had a steady accumulation.

I love that you’re really iterating on this process, and that you have the awareness that the goal isn’t necessarily to get to 100%, because there are always exceptions. Setting realistic targets that are still aspirational, that’s great.

Let’s move a little bit from talking about things on the team level, to talking about things on the individual level. How do you use these metrics for professional development, and for helping your individual team members improve?

It’s part of our general cycle of continuous feedback. We don’t really do annual performance reviews. We do have quarterly check-ins, where we make sure that folks are progressing and exhibiting our core values, and some of those metrics will come up in one-on-one conversations, or in those quarterly reviews.

Again, it’s more of a conversation starter that leads us to ask more questions. There’s no right or wrong value for a particular number. 

Can you share what that conversation might look like? If you’re in a one-on-one, and you have a particular metric or a particular data point, how do you introduce it, and how do you start the conversation?

We would lay out a lot of the things I touched on earlier, in the sense that we look at this stuff to encourage healthy habits. Whether it’s frequent commits, or getting to code reviews on time, or forecasting, we’ll start with what we think is a good quantitative expression of that habit, and then talk about what we see, and where you are.

That leads then into a conversation about your routine, or other behaviors, so we can figure out opportunities for coaching and continuous improvement.