Webinars

Your engineering speed is your organization’s competitive advantage. A fast Cycle Time will help you out-innovate your competitors while keeping your team nimble and motivated. It’ll help you keep feedback loops short and achieve the agility necessary to respond to issues quickly. Most importantly, it’ll align everyone – from the CTO to the individual engineer – around what success means.

To discuss Cycle Time and its implications, we invited a panel of engineering leaders and industry experts for a virtual round table.

Code Climate Founder and Former CEO, Bryan Helmkamp, was joined by:

• Bala Pitchandi, VP of Engineering at VTS
• Katie Womersley, VP of Engineering at Buffer
• Bonnie Aumann, Remote Agile Coach at CircleCI

Over the course of the hour, these panelists covered topics such as using metrics to design processes that work for your team, building trust around metrics, and tying delivery speed to business success.

Here are some of the key takeaways:

Prioritize innovation over semantics.

Bryan Helmkamp: When I think about Cycle Time, I think about the time period during which code is in-flight. And so I would start counting that from the point that the code is initially written, so ideally, the time that that code is being typed into an editor and saved on a developer’s laptop or committed initially, shortly thereafter. Then I would measure that through to the point where the code has reached our production server then deployed to production.

Bala Pitchandi: I define Cycle Time as when the first line of code is written for a feature — or chore, or ticket, or whatever that may be — to when it gets merged.

Bryan Helmkamp: I think it’s also important to point out that we shouldn’t let the metrics become the goal in and of themselves. We’re talking about Cycle Time but really, what we’re talking about is probably more accurately described as innovation. And you can have cases where you’ll have a lower Cycle Time, but you’ll have less innovation. It can be a useful shorthand to talk about (e.g., we’re going to improve this metric), but really that comes from an objective that is not the metric. It comes from some shared goal. That understanding matters much more than the exact specific definition of Cycle Time that you use because really you’re going to be using it to understand directionality: are things getting better? Are they things getting faster or slower? Where are the opportunities to improve? And for that purpose, it doesn’t really matter all that much whether it’s from the first commit or the last commit or whether the deploy is included; you can get a lot of the value regardless of how you define the sort of thing.

The faster you fail, the faster you innovate.

Bala Pitchandi: When I was pitching this to our executive team and our leadership team, I used the analogy of Amazon and Walmart. Most people think that Amazon and Walmart are competing against each other on their prices. But keeping aside the technology parts of Amazon, they’re basically retailers. They both sell the same kind of goods, more or less, but in reality, they’re competing against each other on their supply chain. In other words, you could sell the same goods, but if you have a better supply chain, you can out-execute and be a better business than the other company, which may be doing the exact same thing as you are. And I think that I was able to translate that to the software world by pointing out that we could be building the same exact software as another company, but if we have a better software delivery vehicle or software delivery engine, that will result in better business goals, business revenue, and business outcomes. That resonated well, and that way, I was able to get buy-in from the leadership team.

Katie Womersley: The most interesting business discovery we’ve had from using Cycle Time has been where it’s been slow. It’s been a misunderstanding on the team about what is agile, where we’ve thought, “Oh, we’re very agile.” Because we’ve had situations where we’re actually changing what we’re trying to ship in PRs — we’re reworking lines of code because we think that we’re evolving by collaborating between product managers and engineers with the PM changing their mind every day about what exactly the feature is. And the engineer says, “I’ll start again, I’ll start again, I’ll start again.” And the team in question felt this was just highly collaborative and extremely agile, so that was fascinating because, of course, that’s just not effective at all. You’re supposed to actually get something into production and then learn from it, not just iterate on your PRs in progress. We actually need some clarity before we start coding, and I do believe that that had business impact on knowing what we were shipping.

Bala Pitchandi: We believe in this concept of failing fast. We want to be able to have a small enough Cycle Time to ship customers something quickly. Maybe it’s a bet on the product side, and wanting to ship it fast, sooner and get it into the customer’s hands, our beta users hands, and then see if it actually sticks and if we’ve been able to find the product market fit. That failing fast is really valuable, especially if you are in the early stage of a product. You really want to get quick iteration and get early feedback and then come back and refine your product thinking and product ideas.

Embrace resistance as a learning opportunity.

Katie Womersley: I got quite a bit of pushback on wanting to decrease Cycle Time. Engineers were really enjoying having work-in-progress PRs. They liked being able to say: well, here’s the shape of something, and how it could look as a technical exploration, and some of that was actually valid… But the real concern here is, we are using metrics as a way to have data-informed discussions. It’s a jumping-off point for discussion. It is not a performance tracking tool. And that seems to be the number one thing, and that’s important. We’re not trying to stack rank who has the most productive impact and then fire the bottom 30%. We’re trying to understand at a systems level where there are blockages in our pipes; we’re trying to look at engineering as a system and see how well it’s working. I think that’s very, very important to communicate. I think for software engineering in general, we have a great culture for the most part of blameless postmortems, understanding human factors in engineering, and not attributing outages solely to human error. Basically, you want to take that mindset that you already have from incident response and incident management, and you want to apply that now into team process management as well.

Bonnie Aumann: Esther Derby has a podcast called Tea And The Law Of Raspberry Jam, which actually has an entire episode on coaching past resistance, and the most important part is actually to try to take that word out of your vocabulary. Resistance almost always comes from somebody who really cares and sees value in what is happening. And if you can understand where they’re coming from, you can learn better about how you might introduce something and get a better idea of what will benefit the team and the company. And it’s not to say that you need to be held hostage by one cranky person, but that one cranky person might just have liked a little bit more information for you than you knew before.

Bryan Helmkamp: In speaking with so many engineering organizations and getting started with data and insights, I think it can feel a little bit difficult to get started. It can feel a little bit like, “We have to get this exactly right.” And it’s common that people, as with anything, will make some mistakes along the way. So my recommendations for that are, give yourself the space to start small, maybe just looking at even one tactical thing. “How long is it taking for us to get code reviews turned around?” is a great example. Really focus on building up trust through the organization because trust is a muscle. And as you exercise it, it’s going to grow. Incrementally paint the picture to the team of what you’re trying to achieve and give them the why behind it, not just the what.

Design a Code Review process that works for your team.

Katie Womersley: Something that we do – and this is really controversial – but the vast amount of PRs are merged without review. This will probably shock many people, and the reason we do that is in every asynchronous team: when you’re waiting for review, you lose context…We have a rating system for our PRs. In fact, most of them are small PRs. They’re uncontroversial changes. And we actually don’t need that developer to wait a whole day for somebody to come online to say: ‘Arms up, let’s march.’ It’s just not that risky. Also, we’re in social media management. We don’t make pacemakers. Just from a business perspective: how badly wrong can things go? Most of our PRs are absolutely safe to merge without review. And then you will get PR comments, which are aimed at individual growth and performance, saying this could have been done in a cleaner way, for example. And then on the next PR, hopefully, the engineer would incorporate that advice.

For high profile PRs (e.g., you’re changing Login, you’re changing Billing), yes, that needs to get reviewed before going out … Most people will say it’s really important to have code reviewed before you merge things. And is that nice to do? Yes, it is. But in our very asynchronous team, what is the effect of doing that? Actually, it is a negative effect. So a lot of our code does not get reviewed before merge.

Bala Pitchandi: I couldn’t agree more on the over-relying on reviews. At VTS, we do pair programming a lot. Even when two developers were paired on a PR, we used to still require a third person to review. Later, we just figured that two people working on a PR is enough of a review, so that if you’re pairing on a PR, you just merge it.

As coding days go down, productive impact scores go up.

Bala Pitchandi: I guess, of all the bad things that happened with the global pandemic, one benefit was that we all went distributed. Our Cycle Time actually went down by 20% without having to do anything. Something that you often hear about engineers is that they’re always complaining about distraction. There’s too much noise, people are talking, they want a noise-canceling headset. We were like, you know what? There is actually truth to that because when everyone went remote, guess what? There was less distraction, they had more heads-down time, and they were actually able to contribute to getting the code through the pipeline lot faster. And then we were able to build on that. Focusing on the team-level metrics and encouraging the teams to really focus on their own things that they care about was really helpful.

Bonnie Aumann: We’ve been remote from the beginning. The pandemic made everything more intense. I think is what we really learned. And the thing that became harder was making sure that people took the time and space to actually turn off and recharge. One of the anti-pattern practices is that on a team of very senior people, each person will take something to do and then push it forward. But then, of course, your overall Cycle Time on each of those goes down because you haven’t focused on pushing it all the way through. I think there’s been a lot of cultural outreach from managers to employees to be like, have you hydrated today? Have you done your basic care? When was the last time you saw the sky? It makes it more of a complete package.

Katie Womersley: I have a great mini-anecdote on that. We switched to a four-day workweek to get ahead of burnout with the pandemic. And what we saw in our data was, while the number of coding days went down; obviously, it’s a four-day workweek. We actually saw a productive impact score go up across every single team…We’re getting more done in four days than we were in five days, which is completely wild, but we can show that’s working. We’re in company planning discussions now, and we’re asking, “Should we move back to a five-day workweek to get our goals achieved?” But the data actually shows that we’ll get less done because people will be more burned out.

Agile provides teams with valuable vernacular, but be wary of doing agile by the book.

Bonnie Aumann: I think it’s complicated, but I’ll try and narrow it down. An absolute unit of agile is feedback and feedback cycles. When you’re looking at a thing like Cycle Time, it is a tool to let you know how fast you’re going, but it’s just information. What you do with that information is up to you. If you see people are working seven days a week and you think that’s a good thing, then you’re going to use it to make sure that it’s a good thing.

I will say that one of the things that is beneficial of doing agile by the book, particularly if you’re doing it by The Art of Agile Development or some of the books that really get down into the nitty-gritty, is that you have everybody speaking the same language, you have people using the same words. Because one of the hardest things about getting good metrics on a multi-team situation is making sure that people are using words the same way. And when something opens and when something closes, is when something starts and when something finishes. If you’re using Trello in one place and JIRA in another place, and GitHub issues in a third place, getting that overall view of what your data is, is challenging.

The more you rely on concrete data, the more flexible you can be.

Katie Womersley: It’s so important to look at your metrics and figure out what actually works with the team you have and the situation you’re in, and not just listen to a bunch of people on a panel and be like, “We must do that.”

Bryan Helmkamp: Your point reminded me of an interesting quote about agile and just this idea of process adherence becoming the goal in and of itself. I think the quote was something like, if you’re doing agile exactly like the book, you’re not actually doing agile. It’s inherent. To bring this around to Cycle Time and data, the answers are different for every team. But what I think is really powerful is that by having a more clear objective understanding of what’s going on, that opens the door to more experimentation. And so it can free up a team to maybe try a different process than the rest of the org for a while. Without it just being like: Well, we feel this or that, and being able to combine both of those things into a data-informed discussion afterward about how it went and being able to be more flexible despite the fact that data may make everything feel more concrete.

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Edith Harbaugh, CEO and Co-Founder of LaunchDarkly. She discussed Progressive Delivery and the importance of Cycle Time. Below is an excerpt from the fireside chat portion of Edith’s session, edited for length and clarity.

Hillary Nussbaum, Content Marketing Manager, Code Climate: Welcome to the closing session of this year’s Engineering Leadership Summit, featuring a conversation with Edith Harbaugh, CEO and Co-Founder of LaunchDarkly. Edith and I will be talking about continuous delivery, specifically talking a little bit about what she wrote in the foreword of our upcoming book, The Engineering Leader’s Guide to Cycle Time. Let’s jump right in. Edith, do you mind introducing yourself? Tell us a little bit about what you do and how you got to where you are today.

Edith Harbaugh, CEO and Co-Founder of LaunchDarkly: Hey, I’m Edith Harbaugh, I’m CEO and Co-Founder of LaunchDarkly, a feature management platform. We have customers all over the world, like Atlassian, BMW, who rely on us to get the right features to the right customer at the right time. And we do this at massive scale — we serve trillions, trillions with a T, of features every day.

That’s great. Tell me a little bit about what software development and delivery were like when you first started, and how things got to where they are today, and then where LaunchDarkly fits into all that.

So I started back in the ’90s, and I always loved software because it was a way to bring stuff to life, it was a way to create something from scratch and get it out to the world. The way software was built back in the ’90s was very different than it is now, and that was because you had to physically ship software. So you would have a team of engineers at Microsoft, for example, who would work for three years, and they would release it to manufacturing and print all the bits on a bunch of disks, and then ship them out. And you would actually go to the store and you would buy a box of software, and then you would sit at your computer and you would feed all those disks into your computer, and that would create Microsoft Excel or Microsoft Word. This was pretty cool because then you could use Microsoft Excel, which I still love.

It also created a lot of habits around software — when it went to manufacturing, it had to be perfect. Somebody’s going to buy a 25-disk box of Microsoft Word and then install it on their computer, and it better be good because they’re not going to do that every day. They might not even update it every year. You might have service packs where somebody would go and get an update, but most people are fine if it works okay.

Microsoft had a very small bug in Excel where if you did some esoteric computation, they were off by some fraction, and that was actually a huge deal. So because software was so hard to get, there was a lot of pressure all through the release train to make it perfect. This has to be right, we only get one chance. We only get one chance to get this out to our customers and this has to be absolutely right, we don’t get a second chance.

How exactly do you feel that impacted things moving forward? Even as people started to change their delivery model, do you still see holdovers from that today?

The massive sweeping change that happened — and it’s still happening, to be honest — is from packaged software to software as a service in the cloud. I’m looking at my computer right now, it doesn’t even have a slot for disks, it just doesn’t work that way anymore. You get your software from the cloud, virtually. And what this has really changed is that it’s okay to move a little bit faster, because you can change it. The whole idea that we’re going to have Windows 3.7 Service Pack 6 is just gone now, now you can get a release whenever you want.

And how that’s changed software is it’s really freeing and liberating in a weird sort of way. Think of the poor engineers of the ’90s, when you only had a three year window to work and then ship. It got very political, it got very hard, because you’re like, “I have to make a guess about what people will want three years from now. If I’m wrong, I won’t have a chance to fix it.” So there’s just a lot of polishing and then an inability to adjust on the fly. If you were a year and a half into your release cycle and you realized you were completely wrong, it was just really hard to scrap that. So the biggest change has been with Agile and software in the cloud, that you have a lot more freedom. You could do a week long sprint and say, “Hey, let’s get this out to market. Let’s test this, let’s do this.”

And where do Continuous Delivery and Progressive Delivery fit into all that? Agile is a step past waterfall, but I would say that Continuous Delivery takes that even a step further. How do you see that all fitting together?

So Continuous Delivery was a step past agile in that it was this idea that instead of doing a release every year or every six months, that you could just release whenever you wanted. Jez Humble and David Farley really popularized this theory with a book called Continuous Delivery, where it’s like, okay, let’s make it so you can release any time you want. This was extremely popular and extremely scary at the same time. With big sites like Facebook, it just gave them this extreme competitive advantage. If you can ship 10 times an hour, or 50 times an hour, or 100 times an hour, and your competitors are shipping once a quarter, of course you’re going to have better software. You can fine tune things, you can dial them in, you can get them right. The downside to Continuous Delivery, and why we came up with Progressive Delivery, is that it’s terrifying. What I just said about how you can ship 10 times, 50 times an hour — if you’re a big bank or an insurance company, that’s absolutely horrifying. I’ve got customers who are depending on me, and I don’t want that. Or if you’re an airline, for example, you have regulations, you’ve got people in the field, you cannot have people just check in 50 times an hour and cross your fingers and hope that everything works out.

Even Facebook has moved away. Their mantra used to be, “move fast and break things,” now it’s “move fast with stable infrastructure.” How they got there was Progressive Delivery, which is basically having a framework which decouples the deploy, which is pushing out code, from the release, which is who actually gets it. And with Progressive Delivery, what you have is you have the ability to say, “Okay, I have this new amazing feature for looking at your bank balance, which makes it much clearer where the money is going.” And instead of pushing it out to everybody and crossing your fingers and being like, “Please let people not have negative balances,” let me deploy this code safely, and then turn it on, maybe, for my own internal QA team, my own internal performance testing team, and make sure I’m not overloading my systems, and let me roll this out maybe just for people in Michigan, because they might also have Canadian currency, because they’re so close to Canada. Let me just do some very methodical and thoughtful releases. So you get all the benefits of Continuous Delivery, but you have this progression of features.

What are the benefits to those more frequent releases? Obviously, as you’ve said, you can move more quickly, you don’t have a three year lag on what people want, but what are the other advantages?

You can move more quickly forward, you could also move more quickly back. Because if, from the very beginning, you say, “I am going to think carefully about how to segment this feature so that I can release it discreetly to some people,” that also means that you can roll it back very easily. So the way we used to build code was you used to have this massive, huge, monolithic code and you pushed it out, and then if something broke, you couldn’t fix it. You just had to take the entire release back, which was very, very painful. But if you say, “Okay, I have this new feature for bank balances and I’m just going to push this out alone, and if it’s not working and buggy, I can just turn it off.” That’s really awesome, that gives you, as a developer, a lot of stress relief.

Yeah. And to look at it again from the developer perspective, how can you empower developers to move quickly and to implement Continuous Delivery practices so it’s not just top down, someone telling everyone to move faster, but developers actually being in control and having the ability to move quickly?

I think it’s a restructuring of breaking down units of work into smaller and smaller and smaller units. If I want to move quickly, I need to break down this release that used to take six months into the smallest unit that I can do in a week? And then here’s a bitter secret I learned the hard way, some features don’t need to get built. Some features, if you get two weeks into it and you put it out to the world, and the world says, “You know, we don’t really care about that at all,” it’s much easier just to say, “Hey, we had these bright hopes for this feature, but we don’t need to release it. And if this was a six month project, we can save five and a half months of work.”

Making a small increment of progress and figuring out, “Hey, you know what? We really thought everybody wanted this, but they don’t.” Or, “Hey, we have this six month plan, and once we started going this way, we figured out that we really need to go a little more that way.” And if you are doing a whole six month release, you’re just basically drawing a line. If you’re doing it in two week sprints, you could be like, “Hmm,” and end up where you really want to be. Or even just say, “Hey, you know what? We don’t need to do this. This was a bad idea.” And it’s a lot easier, politically, to realize that two weeks in, than six months in.

Absolutely. It seems like you’d give the team a little bit more control over direction as well. And so given that a lot of teams have gone remote now, either permanently or temporarily — does the importance of Continuous Delivery change at all on a fully remote team? And then, are there particular considerations, is it harder, easier, how does it look?

Continuous and Progressive Delivery are even more important than ever. A lot of the things that you could do when you’re all in the same office, you just can’t do anymore. You can’t just yell out, “Hey, is everybody ready to ship right now?” You could try to do that on a Slack, but people might be getting coffee or taking care of a kid. So you have to have even more controls about what is happening when, what is being shipped out, and who has rights to see that. And you also may need to be able to react very quickly. I keep coming back to financial customers, because in the last six months, they have had, I think, 30 years of progress crushed into six months, in terms of people not being able to go into banks anymore. Suddenly everyone wants to check their balance at home, wire money at home, or transfer money. Before the answer was kind of, “Just go to your branch.” You don’t have that anymore, you have to be online. It’s not a choice, it’s not an either-or anymore. You absolutely have to have online support for a lot of functions.

The same thing is happening, sadly, to a lot of functions all over the world, where it used to be like, “Just get to your office fax machine.” You have to have a truly digital function for everything right now.

Yeah, it’s interesting. So it’s a change, not just for the developers, but a change for the end user, and it’s even more important that this innovation is happening, and it’s happening quickly.

Yeah. It’s happening extremely quickly. A lot of processes used to be half digital, half paper and now, you have to be fully digital.

Do you have any tips for teams that are working to coordinate while they’re distributed and working to implement Progressive Delivery?

Take it in small steps. I talked in the beginning about Microsoft transforming from a three year release to releasing every week or so, and I also said you need to do this very quickly, but you also need to do it right. So get comfortable with some low-risk features first. Don’t say, “Hey, we’re going to move from a three-month cycle to a daily cycle,” that’s terrifying. But if you’re at a three-month cycle, look at, “Hey, are there some low risk features that we could try to do in a week-long sprint? Is there something that we can carefully detach and figure out a basic rhythm before we get more into this? Let’s figure out the issues that we have, whether they be communication, tools, or process, on something where if it fails, of course failure’s never awesome, but it’s not hugely not awesome.”

I mentioned that you wrote the foreword to the Engineering Leader’s Guide to Cycle Time. Where does Cycle Time fit into all this? Why is it important when you’re trying to move to Continuous or Progressive Delivery?

Cycle Time is so important. The smaller the batches of work you do, the more impact each batch can have. If everything takes six months, you just don’t have many opportunities, you just don’t have many at bats. If you break it down so that you can say, “Okay, let’s try something new every month,” even that alone is a 6X improvement every month. If you break it down further, you just get more and more chances.

And the really seductive part of Continuous Delivery for a developer is that it’s really fun to see your stuff out in the world. If you’re an engineer, like I was in the ’90s, and you’re grinding away for months on a project, you don’t really get much of a feedback loop. You get your manager saying, “Hey, keep working,” but you don’t get any real validation from the customer. So if you can break down your Cycle Time so that you can say, “Every week, this is out in the hands of our customer, and they tweeted that they loved it, or they put in a support ticket that they had some issues but they liked it and wanted to work with us,” that’s really, really fun for a developer.

The worst thing for a developer is, number one, the worst thing is you ship something and it just totally breaks. The second worst is you work really hard on something and then nobody cares, and you’re like, “Well, I gave up seeing my kid’s practice, or I gave up this happy hour with a friend because I was trying to get this done, and nobody cares.” Which is just hard. So if you’re in this shorter Cycle Time as a developer, where you’re like, “Okay, we worked hard this week and we got it into the hands of the customer, and here’s the five tickets they already opened about how to improve it,” that actually feels really good. It feels like I am helping somebody.

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Katie Womersley, VP of Engineering at Buffer. She discussed strategies for stepping up and leading without a title. Below is an excerpt from the fireside chat portion of Katie’s session, edited for length and clarity.

Hillary Nussbaum, Content Marketing Manager, Code Climate: I’m here with Katie Womersley of Buffer. Welcome to the latest session in our Engineering Leadership Summit. Do you mind introducing yourself and telling us what you do, and how you got where you are?

Katie Womersley, VP of Engineering at Buffer: Absolutely. I’m Katie Womersley. I am VP of Engineering at Buffer and we do social media management to help marketing teams be more effective and save time with their social media. I have been at Buffer for five years. I joined as a Software Engineer during a phase of self-management, and grew with the company, and helped us get to the place where we are today, which is a engineering team of around 40 folks]. Our fun fact is that we are 100% distributed, no offices anywhere, and have been from day one. That’s something that we’re kind of known for.

Let’s talk about the transition at Buffer from not having managers to having managers, and what that looked like. What did that shift make you realize about the role of a manager?

We didn’t have managers when I joined, and it was sort of the holacracy model of working, which is not a bad way to work, but it wasn’t working for us. Probably because we hadn’t implemented it quite right. And the shift from not having managers to having managers wasn’t a case of, “Okay this isn’t working, you all need to be managed.” It was a case of the engineering team actually being quite unhappy. I speak for engineering because that’s where I was in the organization, and people were experiencing problems like, “I don’t know how I can grow in my career and get promoted. There is no one who can really advocate for me.”

It was very difficult to make progress on well-coordinated efforts and have more impact, because everyone was doing their own thing. We actually had the experience of two teams organically forming and making really fantastic features, which was a big self-management success, but these two teams built exactly the same thing, so of course that was a massive duplication of effort at a small company. We were only 15 developers at that stage, so this was really not a great thing.

I think I was on five different teams in the first six months, and I noticed that the problems I was helping the teams with were things like, “We have a really unstable product roadmap so we’re never making any progress and it’s extremely frustrating. The minute we start going in one direction, somebody else has another idea and then we all change,” or, “It’s really difficult for me to figure out how to grow in my career, it’s really difficult for us to address team dynamics that are dysfunctional. I have a coworker who’s honestly not doing anything and it’s very stressful. I have to work really, really hard but there’s no one to give this person feedback, there’s no repercussions.”

So I kind of went around, just as an engineer, kind of, “Okay, let’s put together a document that we can use to advocate for you getting a raise. Let’s see if we can get these goals to be a bit more stable.” I don’t mind having a conversation with so-and-so, and saying, ‘Listen, you’re really affecting all of us…” So I started doing these acts of service, I would say, and after a couple months, I went to the CTO and I just felt I needed to tell him that I wasn’t coding quite as much as he probably was paying me for. And I just, out of an honesty principle, needed to inform him. And he was like, “Yeah, the self-management’s not working. It’s not. We actually need these kinds of activities done.”

And then I became the first Engineering Manager, and we sort of moved away, as a company, from not having managers. It was very much driven by the employees. We had a couple of really brilliant people leave and just say, “This is utter chaos. I’m not growing. I am not achieving what I want to achieve.” That was a massive shock to the organization, losing really talented people because they just weren’t getting a good work experience. A productive, meaningful, impactful experience.

That really knocked into me the sense that management is an act of service. You are there to make things smoother, better for your coworkers and for the company. You need to bring that value, otherwise, why would we have you? We would just do self-management. Self-management wasn’t unworkable, it was just frustrating. So I have this idea of like, “Well if I’m not valuable as a manager, or if the engineering managers that report to me don’t bring value, that’s a problem.” Engineers don’t need managers to survive. You have to bring that value because there is a viable alternative, in my mind, of self-management.

That’s really interesting, and that’s a unique perspective — managing as an act of service. I think that’s really great. You’ve written a bit about the difference between leaders and managers, and a lot of what you were talking about doing was stepping up and leading without that title, right? You weren’t a manager but you were performing these functions.

Yeah.

Tell us a little bit about the difference between a leader and a manager.

Leadership and management are very, very different. Leadership is a very broad category and I personally believe that everybody can, and ought to, exhibit leadership in their personal lives and at work. I think it’s a wonderful quality. Management is a very specific kind of job. It’s sort of like the difference between creativity and then being a graphic designer.

Leadership would be things like speaking up and sharing your ideas, giving feedback to other people. There’s no reason you have to be a manager to be able to say, “The impact of this on the project is that we’re going to miss the deadline, and that’s frustrating to me.” Anyone can say something like that. Being able to lead by example, I think, is a wonderful thing that many engineers, especially more senior engineers, do. And actually most of the leadership in successful organizations is not done by managers. It is done by individual contributors modeling the culture, interacting in a way that is praise worthy, helping each other, being collaborative.

Management is a really specific nuts and bolts subset. If somebody really doesn’t do their job, you’re the person that needs to sit down and say, “This is the expectation, this is what you want to do.” If it doesn’t get better, you’re the one that’s actually going to have to trot out the script and say, “Today was your last day and we’re firing you now.” These are the specific things that the manager job function does.

But management is a tiny subset of the overall leadership role, and there are many, many ways to embody leadership. What we really want, in an engineering organization, is a lot of senior leaders as engineers leading, setting technical directions, making decisions, being very empowered. And then a relatively small number of managers that are keeping a project on track, running formal processes that need to be run, booking vacations. Doing a lot of these administrative tasks, these career development tasks, and aligning various stakeholder goals. That is a very specific manager job.

If you want to be a leader, management’s just one way of doing that. And I would say it’s a very rigid, narrow way of doing that. Many leaders are going to be more impactful, and I think more successful, leading through other avenues, like being the super influential Staff Engineer that everybody asks, “Well, what do you think?”

What advice would you give to somebody who is an engineer and wants to become more of a leader? Or someone who’s a manager and wants to be more of a leader, in addition to doing the other job functions that you mentioned?

Well, leadership is really adding value to your organization, so that’s what you need to do. My advice would be to look around you at the most immediate possible level. People tend to make the mistake of seeing leadership as this huge mountain that’s far away. Look around at your immediate environment — maybe that’s your project, maybe that’s your team — and see, “How do I add value to the organization in an immediate way?” Maybe there’s a more junior developer that you notice just isn’t really getting a lot of investment. Act as a mentor to that person. That would be leadership. That would be adding value.

It needs to be opportunistic. You need to add value to the organization, but I can’t tell you how because I don’t know where exactly the opportunities are. I would say look at your immediate surroundings, look close to home. See where there’s something that it would be great if somebody did something about, and then try and be that person.

A lot of people get held back because they worry, “Who am I to do this? Who am I to speak up? Who am I to make this change? Who am I to go and re-write some documentation that’s confusing? Maybe I’ll step on toes. Maybe I’ll offend people.” Get over it, is my advice. Very few people are going to actually perceive it as, “Who are you to do that?” And if that does happen to you, that’s kind of the price of leadership. That’s why not everybody does it.

That’s really interesting and I think you’re right that people are held back by that fear of, “What if I step on someone’s toes? What if someone feels like I’m intruding on their work?” How would you say someone who’s doing this might know that they’ve gone too far? Are there any red flags or any things that might signal to somebody, “I should step back?”

It’s a really good question. You can expect some friction when you’re stepping up, but if your relationship with somebody is really degrading I would say maybe you’ve gone a little bit too far. The thing is, people tend to not go nearly far enough, so it’s really like, try to make the other mistake. Try to actually step on some toes. It’s unlikely that you will because most people, especially in engineering, tend to be introverted, hesitant, and we don’t tend to make this mistake. But I would say if you are making this mistake, chances are you won’t be making it with just one person. You might notice that all of your relationships are kind of struggling, or you’re getting friction on a lot of different fronts.

If that’s happening, my advice would be communicate what you’re trying to do, and I think that’s good in general. You can say, “Hey, I’m trying to work on my leadership skills, so I’m speaking up more.” And then the other person will be like, “Oh it’s not that you hate me or think I’m incompetent. You’re just trying to do this thing.” So I would say be really explicit. Say, “I’m working my leadership skills, so I am looking for people to mentor. I’m not trying to undermine the Tech Lead.” And then people will be like, “Oh okay, that makes sense.”

And if you do notice that you’re having friction in a lot of different areas of your life or a lot of different relationships, it may be that you are kind of taking over a bit. And in that case my advice would be don’t panic, drop everything, and retreat back. Just have a conversation around it. Say, “I get the sense that maybe I’m taking over a little bit. I’m trying to lead.”

And I got this advice from our CTO Dan — I had a very heavy-handed meeting facilitation style and he was like, “Katie, it’s like you walk into a room, and you turn off the music, and you make everyone sit down, and then you’re like, ‘I have an announcement.’ Maybe try and be more fluid about it.” And I think the reason I got that feedback from him was I told him, “Look I do find facilitating meetings a bit challenging for me and I feel like I don’t really know how to do it. I’m a bit hesitant, so I might overshoot the mark there.”

I find it can be helpful to tell people, “This is the thing I’m trying to do. This is the skill I’m trying to build,” and invite them to collaborate with you on it. Like, “Please give me feedback on how it’s going,” rather than not telling anyone, and then when you do overstep the mark they’re wondering what’s up with you.

You’re talking a lot about communication, which is an important skill for anybody, but a particularly important skill for a manager, for a leader. Are there other skills that you think are particularly important to hone, or other general practices that somebody who is leveling up in their leadership should adopt?

Yes. Self-awareness. The more senior you become, as a leader in general, the less likely you are to get any feedback. And the feedback you do get is less likely to be helpful. You’re more likely to be praised by people because you are now becoming influential and they will want to impress you, they will want your good opinion.

As you get more and more successful, more and more advanced, you’re also more likely to stagnate because people are not going to tell you what you’re doing wrong, they are not going to give you helpful feedback. They are going to give you generic praise because they want you to like them and they want to impress you. Don’t believe it. It’s very, very important from day one of your leadership journey to try to hone your self-awareness and try to understand: what are your strengths? What are your weaknesses? How are you going to continue to grow and develop as a leader?

They say power corrupts. Management’s a kind of power. Leaders also have a lot of power. If there’s a staff engineer on the team who thinks that another engineer really sucks, chances are that engineer’s career won’t go that well because people really trust this person’s opinion.

So the real question is, how do you make sure that power doesn’t corrupt you? And I think the answer to that is self-awareness. You’re now in a position of power. All people in positions of power will get praised, whether they’re great or whether they’re terrible. And you need to figure out what is actual praise, and what is, “This person just wants me to like them,” praise.

And then at a very tangible level, get a leadership coach. It’s the best thing I ever did. I’ve worked with a bunch of different coaches. This is someone who will try to figure out, “How do we call you on your bullshit,” for lack of a more sophisticated term, and who will help you to build that self-awareness, and to have an accurate view of your strengths and your weaknesses.

And when you say leadership coach, is that a mentor in the organization that you seek out? Is that an outside party?

Pay a professional. Hire someone. It’s like if somebody were to say to me, “Katie I really want to do an Ironman,” I would say, “Well have you thought about getting a personal trainer?” And chances are they’ve interviewed a bunch of personal trainers. This is a personal trainer for your career. You pay this person, they work for you, and their job is to call you out and to make you better. If you’re serious about your career, then get yourself a career personal trainer. You don’t have to do this, of course. It’s totally fine not to. But I think it’s a really smart investment in yourself. People tend to think that only executives get executive coaches. I think that the kind of people that end up executives are the kind of people that got coaches early on. They got coaches when they were like, “I don’t know how to become a Senior Engineer, and I’m going to get myself a coach.”

Mentors in your organization are also good but that’s a completely different skill. That’s somebody that’s going to help provide you with organization-specific knowledge and advice. They are not going to necessarily be responsible for developing you as a person. This is somebody that has their own job, their own priorities, and that’s a very different relationship.

Got it. That’s fascinating. I want to ask you one more question. I’m curious, a lot of what you’re talking about I can picture very easily how it would happen in person. Not that it would be easy, but it’s a little harder to envision how one might take these actions on a fully remote team. Can you speak to that a little bit?

It does depend on your organization, and I believe that being completely remote has a fairly level playing field because everyone is operating in the online office, the virtual office. Everything is being done over whatever your chat platform is, over email, over video. I think that this is most difficult in the hybrid situation, where there is a main office that a lot of people are going into, but you’re not one of those people. And there you need to work a lot harder to make sure that you have connections to the various people that you need to be influencing, building relationships with, getting opportunities from.

My advice in that case would be to really invest in relationships with the people that matter. Identify in your organization who is influential to you. Who has influence that you want to build a relationship with? They can help you see opportunities, they can sponsor you for big projects. Sponsorship means I will speak up and say, “I think Katie would be great for this project.” And then also identify — who are you planning to influence? Maybe that’s a more junior engineer that you think, “Well maybe I can really help be a mentor for them.” Invest in those relationships. Message them, set up recurring video calls.

And the other thing is, make sure that you have a good relationship with your cross-functional peers. A lot of people, when they think about leadership, they really focus on, “I want to influence the people on my team, the people more junior, all the rest. And then I want to impress the people above me.” The people you really want to impress are the people next to you. These are the people who are going to say to their boss, “Oh yeah, this engineer actually is really great.” The Product Manager might say, “I love working with Katie.” Then that Product Manager’s going to tell their Head of Product. That’s going to get back to the Head of Engineering, or your Founder, or whoever it is, and that is way more credible for you, as a leader, than trying to impress that kind of person up the chain directly.

So I would say don’t worry too much about up-the-chain influence. Worry about your sideways influence. Work really well with designers, with other team leads. If you are an Infrastructure Engineer, make sure that you have great relationships with the Senior Engineers on product teams. Make sure that you have that kind of sideways network, because that’s where the real influence tends to be.

And I would say with remote, it’s more of a case of identifying that really specifically. You have to say, “This is the person that I’m going to build a relationship with. I’m going to set up the weekly meeting,” because you’re not going to run into them in a casual fashion. It requires you to be a bit more intentional. It’s not at all impossible.

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Juan Pablo Buriticá, Head of Engineering, LatAm at Stripe. He discussed strategies for implementing delivery metrics, and shared how he got buy-in from his team. Below is an excerpt from the fireside chat portion of Juan Pablo’s session, edited for length and clarity.

Hillary Nussbaum, Content Marketing Manager, Code Climate: Welcome to the latest session in our Engineering Leadership Summit I’m here with Juan Pablo Buriticá, Head of Engineering, LatAm at Stripe. I’ll let you take it from here, Juan Pablo — introduce yourself, and tell us a little bit about what you do and how you got to where you are.

Juan Pablo Buriticá, Head of Engineering, LatAm at Stripe: Of course. Hello Hillary, and hello everyone. Welcome to my kitchen. I figured since we were going to talk about shipping and delivery and metrics, why not try to ship a product? I’m Juan Pablo Buritica, I live in New York City. I’m from Bogotá, Columbia. I’ve been in the U.S for a little bit over a decade, and in New York for a decade. I’m a former chef, turned engineering leader, and I’ve been leading product engineering organizations for a decade or so as well.

More recently I was at Splice, a music company, for three and a half years. I was the VP of Engineering, and we built a distributed team of about 60 engineers within the Americas. I started working with delivery metrics there, and tried to understand how to make the team more efficient without working longer or harder. That led to a few talks, and also finding Code Climate and actually using it in production.

Then earlier this year, I took a sabbatical. I was ideally going to start a consultancy on delivery engineering metrics, but Stripe came along with an offer of working to expand the product into Latin America. It’s a mission that I am extremely motivated by, and that I’ve really been thinking about a lot. I joined eight weeks ago, so I’m just getting started and trying to figure out how all my experience fits into the picture.

So, welcome to my kitchen and thank you for having me.

Thank you for being here, and for having us in your kitchen. It’s a beautiful kitchen. You touched on this a little bit, but you just started a new role, and you’ve spoken a lot about how you used metrics in your last role. How are you thinking about metrics and similar strategies as you settle into your new job?

All right. Before I answer this question, I’m going to tell you, we’re going to attempt to make a mushroom risotto. There are some things that have been prepped. So you can think of this as work, engineering work that has already been scoped and outlined and is ready to be worked on. And then there’s some mushrooms and some onions that I need to chop and prep — this is work that is unscoped.

Now, let’s go to the question. I think of delivery metrics as visibility. At Splice, it was very useful for me to see the bottlenecks that the organization had in our delivery pipeline, and how we could drive efforts to solve those bottlenecks.

Now I’m with Stripe, a much larger organization that has a ton of metrics all over the place. And I am leading a team that is more on the surface, right? We expand the existing product into the region, at least initially. I’m trying to figure out how to better measure or get insight into what the individuals of LatAM engineering are like, what their role is in the delivery pipeline, and how we can measure the bottlenecks they may have. So I’m trying to figure out how to see the delivery cycle, because I have no visibility yet.

And in the past, is that how you’ve typically approached metrics, as a tool for visibility?

They’ve been a tool for visibility since we integrated the first version of our delivery framework at Splice. I remember my boss asked me, “What are the things that we’re even trying to solve?” And I couldn’t say, “I think we’re slow, it feels slow.” I needed to know why we were slow. So I read a bunch, and I found the book, Accelerate, by Gene Kim, Jez Humble, and Nicole Forsgren. I learned a ton about the capabilities that organizations should have, and how you can use metrics like Cycle Time or Deployment Frequency to evaluate your process.

Having these metrics gave me three things. It gave me the language to talk to the team about our delivery pipeline and things that we should consider. It gave me insight into what to measure and how to measure it, and where it matters. A ton of the research that is out there highlights why it’s important to have a high-performing engineering organization. With metrics, you can actually tie organizational performance to engineering and delivery. And that was really, really useful. Because I could talk to the board about how we think of staffing and whether a team was going fast or slow.

And since you’re heading in this direction a little bit, what strategies do you use for talking about metrics with people who aren’t necessarily familiar with metrics, or who aren’t the ones using them?

Metrics have helped me now illustrate portions of the engineering delivery process that aren’t intuitive. For stakeholders or people outside of engineering, Cycle Time as a concept and as a metric has been extremely useful in talking about staffing and throughput.

We are used to talking about velocity in points, and we’ve taken this metric as an actual metric of performance or delivery. But it is a representation of capacity, and it’s very relative. If we have two teams of four engineers, their velocity is going to be relative to the scale they’re using, as well as their skills, and even the work they’re taking on. So it isn’t a good metric for us to talk about the speed we’re actually delivering at. It’s just a measure of capacity, of how much we can take. It can tell us if we estimated the right amount of work and if we can consistently deliver on our estimates, but it doesn’t tell us how fast we are. That has become very useful in executive conversations with product or finance. We can set a realistic timeline when we have a better understanding of how fast we can go.

That’s how we talk about Cycle Time, as the speedometer for the team. And then how do you talk about metrics with your team, whether your team is new to metrics or familiar with them?

That is the most fun conversation to have, and I’ve found that this is one of the pieces engineering leaders are struggling with the most when they try to implement metrics. It’s been interesting for me to see that we talk a lot about being data-driven in our industry, but when we try to have a conversation about metrics and data, there’s a lot of concern, especially for ICs. And rightfully so, because there’s always the concern of, “How are these metrics going to be used against me?” And there is a general mistrust towards management. The hardest challenge for me in implementing metrics at Splice was getting the buy-in of the team.

I approached it in a couple of ways. First, I did have a ton of trust from them, and I had a lot of leeway to cash in on the trust currency that I had. But I still had to make an argument about how we were going to use metrics, and why. I wrote an entire RFC, and that’s how I convinced my team that treating this as a pilot was useful. The second thing I did was, I didn’t give access to those metrics to anyone other than myself and the Director of Production and Engineering. We could eventually give access to other people, but taking access away would be much harder.

There’s always the chance that metrics can be used against people, and since the purpose of these metrics is to measure the delivery pipeline and not individuals, I wanted to make sure that they knew we were measuring a process and not their individual performance. Some of the tools we were using had information about individuals, so I protected the access to that, and I think they trusted me with that.

Over time, I would share reports and I would share different bits of information that would give them more confidence in how we were using these metrics. It is on us as leaders to earn trust and demonstrate that we’re going to use these metrics for what they’re meant to be used for.

How did you choose where to start, and which metrics to measure?

We started by having an onsite with senior engineering leadership, where we tried to identify what we believed were the biggest problems at Splice at the time. Then we looked at what metrics we thought could drive some of those things.

For example, feeling slow was one of these problems. So we started with Time to Merge, or how long does a Pull Request take to merge? We didn’t know what was good or bad, but we said, let’s say all PRs are going to be merged in 36 hours, and that will help us evaluate whether this happens. And if not, what obstacles do engineers have in getting their work merged?

And the second challenge we had was deployment. Our deployment wasn’t automated, so a merge didn’t necessarily mean that the code was accessible for other people to use. And so we created a deployment metric as well, and then started learning through that. It was a very iterative process.

And then how did you use those metrics to inform your strategy, and how did they impact what you might’ve been doing as a manager with your ICs?

Our strategy was to set some metrics that we believe may help us improve our delivery process, measure them, and get a baseline. From there we could try to understand whether they were really out of a normal range, and whether we really needed to improve. And then we would create projects that would help us drive down those metrics. And there was a production engineering team that had the purpose of doing this.

The second part of being very specific about the strategy was that we had to crawl, walk, and then run into delivery. Primarily because we didn’t want to start running and go fast in the opposite direction, delivering a ton of terrible quality product.

So we had an angle on delivery, Cycle Time, and we had a Deployment Frequency metric as well. And then we had one that helped us monitor the quality of what we were delivering. It took us six months to properly deploy this entire plan. The first few months, while we figured out how to measure things, we deployed our own dashboards and we brought on a tool [Code Climate's solution]. This is not a sponsored talk. Once we had some of that visibility, it was easier for the team to know what they were driving towards. And they took ownership. The production engineering team at Splice took ownership of their own metrics and how to drive them. And they, in the end, made it successful.

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Dr. Aneika Simmons, PhD, and Anjuan Simmons, Engineering Coach at Help Scout. They discussed strategies for preventing and addressing burnout on engineering teams. Below is an excerpt from the fireside chat portion of their session, edited for length and clarity.

Hillary Nussbaum, Content Marketing Manager, Code Climate: Welcome. We’re with Anjuan and Aneika Simmons. Anjuan is a Technology Translator, and Engineering Coach at Help Scout. Aneika is a Full Professor of Management at Sam Houston State University. Please, introduce yourselves, and tell us a little bit about what you do and how you got to where you are now.

Dr. Aneika Simmons, PhD: I’m a Professor of Management at Sam Houston State University. I am a Texan, so I was born and raised in Texas. And then I went ahead and became a Longhorn at the University of Texas at Austin. From there, I was recruited to Accenture, where I worked as an Information Technology Consultant. And then from there I was recruited at Cap Gemini Ernst & Young. I did work at Enron for two years, but not on their finances, only on SAP, let me be clear.

I worked for about eight years, and I really wanted to do something that better utilized my gifts and my talents and my personality. So I decided to apply for a PhD program, and eventually I was accepted into the Mays program at Texas A&M University. After that, I went to Sam Houston and I’ve loved it. It’s been great for me, for my career, for my family. And it’s something I really enjoy.

Anjuan Simmons, Engineering Coach at Help Scout: Hello, everyone. Again, I’m Anjuan, and I am an Engineering Coach at Help Scout, where we support people who love their customers. I started my career at Accenture as well, working on large enterprise software projects and making sure that they got implemented. I also worked at Deloitte, and then I did a few stints at startups.

One thing I really love about Help Scout is the opportunity to take a lot of the rigor and discipline that I learned at those huge companies, but also to add the personal touch and care that I learned from startups. And so that’s really how I go about my job at Help Scout.

Great, thanks. Now let’s jump right in. We’re talking about burnout today. What do you mean when you say burnout, and why does burnout matter to us as individuals and as leaders?

Aneika: Over a year ago, Anjuan and I — we’ve been married for 18 years, and we have three, basically teenagers (I say basically, because one is 12) — discussed the fact that we were dealing with burnout. So we started doing research on it. We determined that burnout, as defined by World Psychiatry, is a psychological syndrome emerging as a prolonged response to chronic interpersonal stressors on the job. Stressors are the things that cause stress. Stress is what I feel.

There are three dimensions to this. One of them is an overwhelming sense of exhaustion. The second is a feeling of cynicism and detachment, and the third is a sense of ineffectiveness and a lack of accomplishment.

And why should we care about it? At the individual level, it can impact you emotionally, mentally, and physically with all kinds of horrible things like high blood pressure, not being able to sleep at night, or a racing mind. And then from a leader’s perspective, you should care because, number one, I hope we all care about the people that work for us, but number two, it impacts the corporate costs. People are not able to show up or give their best selves. So, this is something with a big impact, and it’s really important.

And how is burnout different for an individual and for a team? How does it impact team dynamics when it’s just one person versus everyone?

Aneika: As an individual, of course it impacts you. A lot of people think that if I’m an individual and I’m engaged, then I’m not going to be burned out. But the research actually says that you can be both engaged and burned out. Meaning that you can be fully involved and burned out at the same time. It’s not just the people who are out the door.

And so how is it different at a team level? Well, for teams there’s emotional contagion, where your emotions can trigger the same emotions in other people. Stress and burnout are not the same thing, but stress is a precursor to burnout. And that can become part of a team dynamic via emotional contagion, and that’s what we need to look out for.

And then one of the big aspects of burnout is depersonalization. If you’re working in a team and you’re depersonalizing your team members, obviously that’s not a good thing. People start depersonalizing because they have nothing left to giv, and they’re just trying to focus in on the minimal aspects of what’s happening. But that’s not healthy, and that is an aspect of burnout.

What strategies can a manager take to try to prevent burnout before it happens?

Aneika: One thing that we need to do is, we need to build our well before we need it. A manager should know their people. They should know the people who work for them, and have an understanding of their baseline. If someone was always a really patient person, and then their patience with people starts waning, that could be a signal.

And then how do you prevent it? Focus on human relationships. Let’s look at one another in the eye, let’s have these meetings, let’s get to know one another. Let’s talk through what we feel. We do a thing where we talk about the importance of eye contact, just engaging in people, understanding the people that you work with. And then we have a cliche that, if you want to go fast, go alone. But if you want to go far, well, let’s go together. If we’re doing things together, we think that that can help mitigate burnout.

You just mentioned it’s easiest to spot signs of burnout if you’re familiar with how a person works. So, what strategies can one use to get that baseline assessment?

Anjuan: One of my main tools as an Engineering Manager responsible for the health and wellbeing of software developers is the one-on-one. A one-on-one is a regular meeting, hopefully weekly, but it can be biweekly, where you meet with someone and talk about what’s going on with them. I really try to make my one-on-ones different from a status update. I have many other ways to get status updates.

They’re a way for me to meet on a regular basis with the people who report to me and really get to know them outside of the work, but to also get that sense of what is their profile, how are they normally presenting themselves? One-on-ones are a crucial way for me to not only be connected to my team, but to get their profile. One other thing that I do is, in meetings, I do a lot of reading facial expressions and body language. And so over time, I just get a mental model for how this person performs. Sometimes they use lots of hand gestures, or present themselves a certain way in meetings. And so that’s a key thing as well, to know how to read a person’s body language, to know that usually they’re really open, but recently they’re closed. And then you can begin to see that they’re outside of their normal profile, and you can begin to interrogate that data.

At Help Scout, we also do self-assessments every six months, and that’s really a way for everyone to look back and reflect. We ask questions like, what has been motivating you over the past six months, or what’s changed, or what’s been draining? And when you get that information, you’ll begin to read that and you begin to see, “Okay, this person, when we had a lot of change happening at the beginning of January, it really impacted them.” And so having that information is really a great way to get the data to understand where individuals are, and then move forward from there.

You mentioned looking at body language and reading those subtle signals. Given that a lot of teams are remote now, how do those strategies differ? Do you find that you need to establish a new baseline before making an assessment?

Anjuan: Help Scout was built from the beginning to be fully remote. Going on more than eight years, the company was built to be global and to work remotely. If your company was built from the ground up to be remote, or you’ve been that way for a long time, then it’s really about continuing those practices. Regular one-on-ones, self-assessments, things like that.

In a remote culture that’s new to a company, if you are maybe thrown into working remotely due to current conditions like the global pandemic, then you have to understand that one, this is not normal. I’m a big fan of working remotely, but I know that a lot of people are not getting a really good first taste of it. Often you’re working remotely with a spouse who’s also been thrown into working remotely. You may have to share a space with that person. There may be children you now need to help with their work. And so I think that being aware, especially now, that this is not normal, and not expecting the team to be normal, is okay.You have to give the team time to figure out their new normal.

One tool that we use at Help Scout that I really like is called Fika. And Fika, loosely translated, is from a Swedish word that means to take a break, get something sweet, like a pastry, and then get a nice beverage, usually coffee or tea. And then we just, we typically use Zoom, hop on a video conference, and we just chat — not about work, but about each other and what’s going on. And so that’s a way that we are able to, even though we’re remote, to connect with each other. There’s also a tool called Donut, which is a Slack app that will randomly pair people for Fikas. And that way, not only with the Engineering Department that I sit in, but with Marketing, Sales, et cetera, I’m able to build those relationships even though we are a remote company.

We are not able to do this for the foreseeable future, but having a retreat is also crucial for a remote company. At Help Scout, we typically have them twice a year.

Are there any other special considerations when it comes to remote teams? We’ve been hearing a lot about Zoom fatigue. Are there other things that maybe you wouldn’t have to think about when you’re all in the same place, but that come up in a remote situation?

Anjuan: Yeah, for sure. Two quick things. I’m very lucky to work at Help Scout where we got a stipend for our home office, because they don’t assume that everyone has the stuff they need at home. If companies can provide that support to help everyone working remotely, especially if they were just thrown into it, that is super helpful. The other thing I would say is that often when you’re working remotely, you don’t have a commute. And most people don’t realize that’s often a really good getting ready time. You may listen to podcasts or to music or do different things, catch up on the news from the radio. And then when you’re leaving work, you have that time to decompress.

But when you’re working remotely, you don’t have that commute. That nice bookend to your work day. So, I would say have some kind of ritual — don’t just spring out of bed and hop on Zoom and start working. Maybe take a walk around the block, or make a nice cup of coffee before you start working, because it’s really easy to work a lot more than you’re used to because you don’t have those natural breaks in your day.

Aneika: I know for myself, I wasn’t really on Zoom that much until everything happened with COVID-19. And so if you could have blocks in your day where you say, “Well, no, I’m not having any Zoom meetings at that point,” that helps. Because Zoom fatigue is real, the stress of making eye contact. When you’re on the phone, you can walk around and do things, but in Zoom meetings, some people may feel a little bit held captive.

That makes a lot of sense. We’ve been talking a little bit about preventing burnout and causes of burnout, but obviously it’s not always preventable. What steps would you recommend that a manager take to address burnout when they become aware of it?

Anjuan: As a manager, it’s really important to understand a person’s baseline profile. And ideally what you’ll be able to do is to say, “Okay, this person reports to me, and they’re beginning to diverge from their baseline profile. They’re acting in a way that is an anomaly from everything that I’ve seen before.” And then the key thing is that don’t diagnose that person. Don’t say, “You have burnout, here’s what we’re going to do.” That is something that a professional should do, and that person may not respond well to you trying to diagnose them.

What you do instead is you share observations. You say, “Hey, I’ve seen you typically log on if you’re remote at nine o’clock in your local time, you’re getting on at around closer to noon.” Or, “You typically don’t introduce a lot of bugs into the system, but I’m seeing more bugs that are introduced by your code.” Or, “You typically are more thoughtful and intentional when you comment on pull requests, and now you’re just writing one sentence.” And so by doing that, you can say, “This is what I’m observing. What do you think is going on?” And often it’s in that conversation that you’ll begin to glean what’s happening. And then as a manager you can do things like, “Okay, let’s look at your workload, and you know what? Out of these five things, only these two are really valuable. Let’s just focus on that.”

And in our framework, we talk about having the need to burn down distractions. And so by doing that, you can focus on what’s really valuable. I find that if I can narrow down what my team has to worry about to just one or two things in a given sprint, that goes a long way toward releasing the stress that builds up when we try to keep a lot in our minds. I really try to make sure that my team only has one or two things that they have to think about, because in a world where there is a global pandemic and there’s a lot of civil unrest and a lot of disruptions to the economy, the last thing I want my people to worry about is work. And so I try to make work as simple as possible.

What would you recommend that people do if they’re feeling burned out? Or if they notice a team member is burned out, but they’re not that person’s manager, so they don’t necessarily have the ability to say, “Let’s focus and take things off your plate?”

Aneika: The first step is acknowledgement. So, for you to acknowledge that you’re burned out. You would ask yourself, are you feeling exhausted? The things that used to really light your fire and make you passionate about work, are they still there? How healthy are your relationships at work? Are you engaged with people? Those types of things are important. One of the main things that we do to mitigate stress is, we go for walks every day. We go for walks in the evening and just kind of decompress and talk. So, the first step is acknowledgement and accepting that there’s nothing wrong with you. We’re human beings. And that we get to a point sometimes where we feel that, “My plate is full, I have nothing else to give, and I have to address this.”

Anjuan: To the latter part of the question, which is, I’m not this person’s manager, but I see that they’re burned out — if you have the right relationship with that person, you can share your observation. Again, don’t try to diagnose them as being burned out, but say, “Hey, I’ve been noticing this.” Like my wife said, “You used to be really energized by working in our CI/CD pipelines, but now you seem to have slowed down there.” Share those observations. And then what you can do is say, “Here are some things that have worked for me when I’ve gone through that.

The ideal is that you’ve already built up what we call burnout resistance in your own life, and you’re able to model that to the other person. If you don’t feel that you have the relationship to be able to share those observations, it’s really important to find someone in the organization who does, and candidly share those observations with that person

Aneika: And I’ll just say real quick that all of these types of things that we’re talking about requires a certain level of psychological safety at your job. So you have to have an organization where you feel that you can be vulnerable. And if you can’t be vulnerable, then maybe you really won’t know what your employees, or the people who work for you, or work with you, are going through. The organization has to have a culture where people feel like they actually can be vulnerable and say how they truly feel.

I’m curious about what you just said, that it is important to be vulnerable as a manager, as a leader. Do you have some tips or strategies for people who aren’t necessarily as comfortable or as practiced with that?

Aneika: Well, there are different types of personalities, like my husband is an introvert, and I’m an extrovert. Of course not all introverts and extroverts are the same, some personality types might be more comfortable sharing things that are close to your heart. So, you would need to keep that in mind. But one of the things that I would say is just make sure you develop a healthy relationship with at least one or two people on your team. I know that as teams get larger, you can’t be close to everyone, but you do want to try to have that interconnectedness. That is really important so that when things do come up, you feel comfortable sharing.

Anjuan: Yeah. And at Help Scout, we use a tool called Know Your Team, which is a website that asks a question every week and then people respond to it. It seems kind of trite, but by just sharing those answers, just sharing more about what you think outside of work…you’ll begin to make the first steps toward having that relationship. And then building that culture where people do feel a sense of a psychological safety. Aneika and I have often said that healthy teams build healthy code, and people can be healthy obviously by taking care of their physical body, by exercising and eating properly, and by having relationships that are strong and meaningful. But I also think if people can bring their authentic self to work, then you’ll get their best work.

As part of this year’s Engineering Leadership Summit: Virtual Edition, we spoke to Ale Paredes, VP of Engineering at Code Climate. She discussed her strategies for managing with metrics, and the importance of gathering both quantitative and qualitative data. Below is an excerpt from the fireside chat portion of Ale’s session, edited for length and clarity.

Hillary Nussbaum, Content Marketing Manager, Code Climate: Ale, can you introduce yourself and tell us a little bit about what you do and how you got to where you are now?

Alexandra Paredes, VP of Engineering, Code Climate: Sure. Thank you, everyone, for joining us today. I’m really excited to be here and discuss how I incorporate data into management. I am the VP of Engineering here at Code Climate. I joined Code Climate three years ago, and it has been really rewarding to build products for engineers and engineering leaders. I grew up in Venezuela where I studied computer science, and for most of my career I worked for startups remotely in the US and in Europe. Four years ago I moved to New York, and I joined Code Climate shortly after that.

My passion is distributed systems and reliability, and then leadership and engineering management, and growing the engineering team at Code Climate.

You’ve spoken a lot about the way you use data in your management. What’s interesting to me is the fact that you always emphasize that it’s not just about the data. That there’s a human side, too, and it’s about the qualitative and the quantitative information. Can you tell us a bit about your management philosophy and the role that data plays in that?

I start my management relationships with the foundation of trust, respect, and accountability. As a manager, my goal is to make sure that everyone on the team has the best environment to do their best job, so our team is able to deliver on business goals, and business vision. Quantitative data is a tool that I use to support my goals, but it’s not the goal in itself. I usually talk about feelings as much as I talk about metrics. When I am setting goals or I am finding opportunities for improvements, I read the data and I take into account the information that’s given to me, but then I use that as a starting point to gather more context — that could be through one-on-ones with my direct reports, or other meetings.

Where do you start when you’re working with data? How do you know what you’re looking at, if it’s good, if it’s bad? What’s your starting point?

Typically, either I or someone else has questions. Maybe I think we are not moving as quickly as we could, or we are not delivering at the rate that we should be delivering, or we are not achieving what we should be achieving. Usually I start with that first question and then get more information.

A year-and-a-half ago, I was in a position where I needed to understand why our team’s Cycle Time was over time. I started by creating a mental model of all of the steps our team was taking to deploy code into production.

Just creating the mental model is already a really good exercise to make sure that everyone is on the same page, and if there is any confusion, that’s a good moment to talk about it and make sure you make the changes or address the miscommunication. Then once you have that model of how your process flows, how code, for example, gets into production, you can start adding in data.

So the more general metric would be Cycle Time, but then there are multiple steps to how code gets into production, and you can break down that metric into more granular information to identify areas for improvement. For example, if the team is taking a lot of time to open pull requests, you would zoom into this area of the process and try to identify what may be impacting the team.

How do you figure out where you should zoom in, and what’s worth further attention?

I try to start with general metrics, so Cycle Time, for example. For us, the way we get code into production is, an engineer writes code, opens up a pull request, and then that code requires review. Either there is a request for changes, or it’s approved. If it’s approved, then the pull request is merged and deployed. So I kind of break down the process into its sub-processes.

Once I notice areas that have changed over time — like let’s say we used to open PRs very quickly six months ago, but right now it seems to be taking us much, much longer — that tells me maybe there is something that I need to zoom in on, even if there are opportunities to improve other areas of our processes. It seems like something that we used to be doing really well, but it has changed in a way that’s not desirable.

Once you are zooming in, bringing in context by slicing the data can be really helpful. That can help you, for example, understand, if there is a team within your organization that is doing really well, what are the behaviors, what are the practices that they are applying, so you can try to translate that into the entire organization.

Got it. You mentioned before that you work with this combination of quantitative data and feelings, qualitative information. So where does the qualitative part come in, and what do you do once you have that quantitative information?

So once I notice something that requires more of my attention, I will use one-on-ones to try to get more context, so I can understand either what someone is doing that could impact the way they are working or the way they are communicating, and then in our case we also use retros to talk about the way we work. Some teams use retros to talk about the issues they’re working on, but we talk about how we’re working with product and with design, and how we are communicating and managing our processes.

And once you’ve identified an opportunity for improvement, where do you go from there?

Usually we identify more than one area of improvement, but my philosophy is that it’s best to focus on improving one thing first and then move onto the next thing, rather than trying to improve too many things at once. I try to choose the most impactful area for improvement.

So, let’s go back to the idea of wanting to improve our ability to deploy code into production more quickly. If I know we take too long to open pull requests and also that our code review processes need help, opening pull requests happens first. Improving that bottleneck first is more impactful, even if we know we have other areas to improve. So I try to prioritize what would be the most impactful area of improvement, and then I discuss potential changes with senior managers on our team, as well as how we can set targets and measure progress.

You mentioned that when you share the mental model it’s a great opportunity to make sure everyone’s on the same page, and you’re talking now about discussing things with senior members of your team. How do you decide what portion of the process to share with each level? How looped in are the engineers into the fact that you’re looking at metrics, and which metrics you’re looking at?

I’m in a unique position where my team is building a product based on engineering metrics, so I am usually very transparent about the information I’m looking at. They are part of our company KPIs, so not only our team, but other teams have visibility into it. The way I usually share that information is I send a weekly update Monday morning with an update on what happened last week. It includes some quantitative data but it also includes some qualitative data, like what events could have impacted certain areas of our workflow. I send out that information, and if anyone has any questions I share more context.

I use our metrics on a team-level because I think the most important thing, at least for the size of our team right now, is to make sure that we are all improving together. My focus is on team-level metrics, and then in some cases if I need to, I may set individual target goals, but that’s not a practice that I do all the time.

You’ve made it clear that metrics are only relevant in context, and that you need to have conversations — there’s more that’s important than just the number. But how do you make sure that your team feels that way as well? That when you set a target people aren’t just singularly focused on that target? How do you create the right culture around metrics on your team?

The targets usually focus on improving processes and how we are working together, but we still have goals that are not related to a metric in itself, which I think is very important. We want to improve how we are working, and that means over time our metrics will improve in the direction that we’d like. But at the end of the day our focus as a team is to make sure we are delivering a product that is valuable for our customers, so a lot of our goals are based on what are the objectives we’re trying to achieve this month, this quarter, and that translates into business goals and customer goals.

How do you match those business goals with team level goals and team level metrics? What’s that process like?  

Business goals are more related to product deliverables, and then in terms of how I’m using metrics to measure progress, we use KPIs. We have sets of success KPIs, health KPIs. So an example of a health KPI for us is making sure that the system is healthy. So we track the amount of incidents that we’re having, and then if something seems to change on that front, we take action right away. We balance creating goals that are related to a product, while making sure we’re also paying attention to our KPIs help us calibrate how we use our time and which area we’re focusing on.

We’re in a period where there’s a lot of change, there’s a lot going on. How might metrics and the data that you’re looking at have helped you lead your team through those transitions?

To give you a little bit of context on what the team used to look like before the pandemic happened, we had an office in New York and most of our team was in New York, but we also have engineers in Brazil. So when we moved to remote, we thought we were somewhat prepared because we already had people who were working remotely. But we saw that was not the case, and having metrics was really helpful to understand trends. For example, our Rework, which is a metric that lets you see how often you are changing code that was recently changed, had increased. Our Cycle Time was increasing over time.  

So there were little things that told me, even when we were somewhat prepared to work remote, this was still a major shift. That helped me have conversations to understand how we were communicating about projects in general, how well we were helping less-experienced engineers to break down their work. How we were communicating not only in private channels, but also in public channels. So for example, right now we try to have most of our conversations in public channels with the rest of the team, so we can all be on the same page as much as possible.

And so you were able to look to certain metrics and sort of find areas where things weren’t maybe working as well remotely and then work through those. That’s very cool. How involved was your team in helping work through those pain points and figure out solutions?

Very involved, especially since the team grew right at the moment we transitioned into working remotely. I am not involved directly anymore with the engineers. I have two tech leads who are leading their respective teams, so they were very involved in relaying feedback on how the team was doing with working remotely, and sharing some of the communication challenges they were having, and then we worked together to find ways to improve.

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.

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.

“Meetings are expensive in person, and they’re even more expensive remotely. There’s a psychological overhead to bringing people together in a remote setting,” told us Noah Davis in his webinar on how engineering leaders can use data to run more effective remote meetings.

As teams go remote, the function of meetings changes. Team members lack context and use meetings to play catch-up rather than to discuss and make critical improvements. But when managers use remote meetings as status updates, they’re squandering the opportunity to help their team in the long-term.

In addition to advising hundreds of customers on data-driven best practices, Code Climate Co-Founder and VP of Customer Success, Noah Davis has nearly a decade of experience helping both developers and managers improve the speed and quality of engineering work.

"Assume best intentions of your engineers. Focus on the work, not the individual. Look for ways you can help."

In this webinar, Noah explained how to dig into engineering data from Velocity reports to get your team on the same page and keep meetings focused and productive. He shared actionable tips for spotting daily, weekly, and monthly trends in your data, so you can ensure that:

• Stand-ups are about unblocking engineers, not catching managers up
• Retros are about helping your team diagnose problems and process fault lines, not venting
• 1:1s are about constructive feedback and career development, not micromanaging

Noah pointed out that by walking into meetings already context-aware, you can replace check-ins with more informed conversations about how the team can stay on track.

Access the full webinar for free here.