Webinars

Engineering is an expensive department. And given that global circumstances are cinching purse strings even tighter, it’s never been more important for a CTO to track and optimize where the money is going.

In this 45-minute webinar, Code Climate Engineering Data Specialist, Bob Brown, talks about how to use data-driven insights to build a leaner process at scale and get the intended ROI from your organization.

Bob covers how to dig into engineering data from Velocity to answer questions like:

• How does our Time to Market compare to industry standards?
• Why does engineering typically get blocked? What process changes can we make to eliminate bottlenecks?
• What are the distinguishing characteristics of our strongest teams, and how can we replicate them at scale?

To uncover your own data-driven insights, request a demo of Velocity.

To create a culture that both motivates engineers and improves their ability to drive innovation, managers need a comprehensive picture of where their team members are succeeding and where they can improve.

In this 45-minute webinar, Code Climate Engineering Data Specialist, Nico Snyder, talks about how to create measurable improvement (20% or more) in Cycle Time and team performance with holistic visibility into engineering work.

Nico covers how to dig into data from Velocity’s newest features to answer questions like:

• How are teams or developers performing? How do we improve?
• How do we drive continuous improvement across engineering processes?
• How do we communicate engineering success both within the department and to others in the organization?

If you’re not already using Velocity, you can request a demo here.

While most board decks will include business metrics like ARR, churn rates, and cash in the bank, these metrics only provide a snapshot of business health. They don’t speak to the strategic priority of how you plan to deliver real value. They also don’t illustrate engineering’s ability to execute on product timelines.

In this 30-minute webinar, Alexandra Paredes, VP of Engineering at Code Climate, runs through her method of communicating with technical and non-technical stakeholders in the board room. She covers:

• Representing both the speed and direction of your engineering department’s work
• Summarizing engineering challenges and opportunities
• Visualizing improvement against OKRs quarter over quarter

Armed with this framework, an engineering leader can illustrate the importance of their department and engage senior leadership on the best way to endure and thrive during these unprecedented times.

To incorporate this data into your own board deck, request a demo of Velocity.

Innovation is critical to startup success. To satisfy your customers, stay ahead of your competition, and keep your team engaged, you need to be shipping often — and at high quality.

But how can engineering departments measure and improve their ability to innovate?

With the right data, you can streamline processes and unblock your engineers, clearing the way for developers to work on fresh ideas and deliver new value to your customers.

In this 45-minute webinar, three startup leaders share how they use data to boost innovation on their engineering teams. You’ll hear from:

• Edith Harbaugh, CEO and Co-founder, LaunchDarkly
• Santiago García, Co-founder and CTO, La Haus
• Dalia Havens, VP of Engineering, Netlify

Here are some of the key takeaways:

Innovation requires iteration.

Edith Harbaugh: One of the things that really helped us innovate is we just had more swings at bat. If you’re in a cadence where you can release not every year, which is incredibly stale if you’re in the app store, but every month, or every week, and then do backend updates so you can update hourly – you’re going to win. ‘Cause part of the fact is that not everything you do is going to be perfect. But you just have to keep swinging and swinging and swinging, and one of those things is going to land.

Dalia Havens: One of the things I love about the way at Netlify we define innovation is that we focus on the simplicity of the solution to these complex problems…It’s about those quick iterations. It’s a learning journey. And it’s really hard to figure out which path will take you to the right solution if you’re not iterating.

Santiago García: To bring you some context, [La Haus is] in Latin America. So in this market, we have to invent actually everything. We don’t have [real estate] databases, like you in the US have…From here, we have to create everything from scratch. And that means you need to start to create everything with a good pace, with very fast experimenting because there are things that you don’t know.

Building a metrics-driven culture.

Dalia Havens: [Metrics] are operational measures. They are not punitive, they are very much a tool to help us improve at the end of the day.

Part of my responsibility is to create a quality of life for developers to do their best work. How are we measuring that? How are we removing roadblocks? How are we identifying that there was a roadblock? That’s where the data comes in. And when you bake it into the culture and not make it a taboo to talk about or hide it from this stakeholder or not communicate the incentive behind it, it creates a different shift…creating that metrics-driven culture is actually really important for the success of using metrics in your organization.

Edith Harbaugh: I think you really need to have metrics that people buy into in terms of, “How often do we ship?” because that means that I can feel pride that my code is out there. “How often are we able to roll back?” because that means that I can feel confidence.

Santiago García: What I think about it is what Peter Drucker said — “What you don’t measure, you can’t improve.” And that’s very important, that is very cultural. You can give feedback based on metrics, and people [can] feel comfortable with that. At La Haus, we have two values at the company…We have one that is, “Strive for more.” People want to improve, so it’s good to show the metrics, so they can see they are doing things [that] could have been better. Also, we have something that is called, “Extreme openness.” When you are open to feedback…you can take your data and make these data-informed decisions. For me, it’s very cultural.

Data provides objective insights.

Santiago García: When we started working remotely, some engineers started to complain — not complain, but they started to say, “Hey, we’re working more hours, we are exhausted, we have been working more.” My feeling was that we were delivering the same amount of work or less. But in that moment, I couldn’t measure [that feeling]. The first decision was to start measuring that, so I started using Code Climate.

Edith Harbaugh: When you get bigger, you just have to get a lot more deliberate about communication and about what you’re measuring and how teams work together. And then also still make sure that you are measuring, “Are we moving forward? Are we having meetings for the sake of having meetings?” So one question that the engineering side has to understand is, “How much new versus old features are you doing?” Like tech debt versus new, which is a really tricky balance. If it swings too far in either direction, you know that you’re going amiss. If 80% of my time is on maintenance, you’re not innovating. If 100% of my time is on innovation, and I’m not doing any code maintenance, stuff is going to start breaking in the field. So just keeping a close eye on metrics like that, in terms of “Does the team have the right pressure and direction?”

Dalia Havens: I fell in love with metrics because…through this organic journey to engineering management, I found that a lot of times without them, it’s a gut-feel conversation. And those are really hard to have without it seeming personal or you’re saying that someone is not putting in more hours or the right level of effort and so on. So what metrics have allowed us to do is sort of come objectively to the conversation. We are all trying to remove these roadblocks that are getting in your way and so on.

Transparency is critical.

Santiago García: [Transparency is] very important…I went with my team in a one hour meeting, I showed them the tool, how we are going to measure the process. And this was very clear, it was to improve the process. It was not going in a very punitive way or something like that. We wanted to improve our process, and everyone wants to improve. Actually, the next day, all the engineers were asking me for access to the tools so they could see their metrics and how they could improve them.

Dalia Havens: I’ve had an experience with an established team where it…the team was not talking about them being blocked to ship. And it was because we had metrics that we could see our week-to-week trend. And we’re like, “This is weird. For some reason, all of a sudden, we are not able to get things to production. Let’s talk about it.” So I found that it’s a really, really great way to be transparent and honest with everyone on the team. And also disarms sort of that tension. Because at the end of the day, just like all the the monitoring tools we have in infra, it’s to allow us to improve and iterate and create a better environment for development.

Innovation can be game-changing or destructive — make sure you’re moving in the right direction.

Edith Harbaugh: I think innovation in and of itself is a hard word. I think there’s the bright shiny answer that innovation is game-changing stuff that moves the business forward. The flip of that coin is innovation is sometimes harmful and destructive. And you don’t really know sometimes until you flip that coin, what way it’s going to land.

Dalia Havens: A product full of bells and whistles that are not really giving a seamless user experience is not going to be as effective or as useful to the potential end-user as one that is more thought out…Innovation is a big word for us. What I translate that to is iteration. Are we able to iterate? Are we able to learn? Do we have the tools to be able to learn to gradually get things out, or to decide on killing something? …having these tools allows the team to really define what is success or how are they working toward that success metric.

Santiago García: I think is very difficult to innovate in the tech team if you are not aligning with your business, with your customers…For my team, the engineering team, its mission is to deliver value to our customers as fast as we can, with the best quality.

To learn how to start gathering insights from your own data, request a consultation.

When teams go remote, the function of meetings changes. Lacking context, team members end up using meetings to play catch-up rather than to discuss and make critical improvements.

In this 45-minute webinar, Code Climate Co-Founder Noah Davis discusses how leaders can use data to better support their remote teams. He explains how to dig into engineering data from Velocity reports to get your team on the same page and keep meetings focused and productive.

You’ll learn how to use:

• Stand-ups to unblock engineers
• Retros to diagnose problems and process fault lines
• 1:1s to give constructive feedback and encourage career development

To start bringing data to your remote meetings, request a demo of Velocity.

As you prepare for your board meeting, you might be struggling to find some good news to share with the board. Sure, it’s a mistake to go into a board meeting pretending everything is going well — board meetings are a valuable opportunity to share your startup’s challenges and get guidance from a panel of trusted advisors.

But your current challenges don’t tell the whole story. It’s also important to highlight your company’s opportunities and to articulate your strategic vision for the coming months. To do that, you need to look beyond any suffering short-term KPIs. Revenue may be flagging, but other signs point to your company’s resilience and its ability to hold its own in a tough market.

To have an informed conversation about your company’s future, you need to communicate your company’s ability to add new value to your product, the speed at which you can ship that new value to users, your customers’ response to those new features.

You need to look at your company’s ability to innovate.

Innovation is a leading indicator. It’s not predictive, but it can hint at your company’s chances of future success. Software companies that are able to keep delivering new value to their users will be better positioned to retain their customers, outrun their competitors, and recover from a difficult year.

The shortfall of a feature laundry list

Of course, there’s no universal metric for innovation. At board meetings, engineering departments often share a list of completed features to communicate the value they delivered to users in the previous quarter. To signal the value to come in the upcoming quarter, many also share a list of features planned.

While important, a features list does not go far enough to capture the work the engineering department is doing. Features may require more work than anticipated, and priorities may change throughout the quarter. A company that decides to shift focus and enhance security protocols may not deliver on its planned feature list for that quarter. Still, those security upgrades represent innovation. They’re improvements that deliver real value to the customer, and they may even be critical to landing new deals or securing a foothold in a new segment of the market.

In her recent webinar, Code Climate’s VP of Engineering, Ale Paredes, shared her strategies for communicating with technical and non-technical stakeholders in the boardroom. Watch to find out how she uses engineering metrics to report on engineering’s challenges, progress, and opportunities.

Metrics that illustrate resilience

Complement the usual features list and any engineering KPIs you’re already sharing with metrics that highlight your company’s success in three key areas:

• Designing and implementing new value for your users
• Quickly shipping those new changes
• Turning your product into a must-have solution for your customers.

Feature Cycle Time

Feature Cycle Time speaks to your company’s ability to add new value to your product. It’s a measurement of the time it takes for a new feature to go from idea to implementation and can help you understand whether your team is working together effectively.

If the design process is efficient, product specs are clear, and product and engineering are aligned, it will be reflected in your Feature Cycle Time. A low Feature Cycle Time indicates that your team is frequently finding new ways to add value for your users.

Delivery Cycle Time

Delivery Cycle Time is a measure of how long it takes for code to go from a developer’s computer into deployment. It’s a way to isolate the execution portion of the development process and measure engineering speed independent of the variable feature design and planning process. Teams with consistently low Cycle Times are shipping code often, reliably and quickly delivering new value to users. This puts them in a strong position to outpace their competition.

Customer Retention Rate

A consistently high Customer Retention Rate demonstrates that your team is moving in the right direction and that their innovations are speaking directly to your customers’ needs and adding essential value to your product. If your Customer Retention Rate is high in a time when your customers are likely looking to make spending cuts, that’s a strong indicator that your product is a must-have for your users.

Keep moving forward

It’s been an unbelievably difficult year, and it’s likely that your short-term metrics reflect that. But with the right data, you can keep the conversation focused on productive ways to move forward.

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.