Engineering Leadership Summit: Katie Womersley, VP of Engineering at Buffer
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.
Related Articles
Navigating the world of software engineering or developer productivity insights can feel like trying to solve a complex puzzle, especially for large-scale organizations. It's one of those areas where having a cohesive strategy can make all the difference between success and frustration. Over the years, as I’ve worked with enterprise-level organizations, I’ve seen countless instances where a lack of strategy caused initiatives to fail or fizzle out.
In my latest webinar, I breakdown the key components engineering leaders need to consider when building an insights strategy.
Why a Strategy Matters
At the heart of every successful software engineering team is a drive for three things:
- A culture of continuous improvement
- The ability to move from idea to impact quickly, frequently, and with confidence
- A software organization delivering meaningful value
These goals sound simple enough, but in reality, achieving them requires more than just wishing for better performance. It takes data, action, and, most importantly, a cultural shift. And here's the catch: those three things don't come together by accident.
In my experience, whenever a large-scale change fails, there's one common denominator: a lack of a cohesive strategy. Every time I’ve witnessed a failed attempt at implementing new technology or making a big shift, the missing piece was always that strategic foundation. Without a clear, aligned strategy, you're not just wasting resources—you’re creating frustration across the entire organization.
Sign up for a free, expert-led insights strategy workshop for your enterprise org.
Step 1: Define Your Purpose
The first step in any successful engineering insights strategy is defining why you're doing this in the first place. If you're rolling out developer productivity metrics or an insights platform, you need to make sure there’s alignment on the purpose across the board.
Too often, organizations dive into this journey without answering the crucial question: Why do we need this data? If you ask five different leaders in your organization, are you going to get five answers, or will they all point to the same objective? If you can’t answer this clearly, you risk chasing a vague, unhelpful path.
One way I recommend approaching this is through the "Five Whys" technique. Ask why you're doing this, and then keep asking "why" until you get to the core of the problem. For example, if your initial answer is, “We need engineering metrics,” ask why. The next answer might be, “Because we're missing deliverables.” Keep going until you identify the true purpose behind the initiative. Understanding that purpose helps avoid unnecessary distractions and lets you focus on solving the real issue.
Step 2: Understand Your People
Once the purpose is clear, the next step is to think about who will be involved in this journey. You have to consider the following:
- Who will be using the developer productivity tool/insights platform?
- Are these hands-on developers or executives looking for high-level insights?
- Who else in the organization might need access to the data, like finance or operations teams?
It’s also crucial to account for organizational changes. Reorgs are common in the enterprise world, and as your organization evolves, so too must your insights platform. If the people responsible for the platform’s maintenance change, who will ensure the data remains relevant to the new structure? Too often, teams stop using insights platforms because the data no longer reflects the current state of the organization. You need to have the right people in place to ensure continuous alignment and relevance.
Step 3: Define Your Process
The next key component is process—a step that many organizations overlook. It's easy to say, "We have the data now," but then what happens? What do you expect people to do with the data once it’s available? And how do you track if those actions are leading to improvement?
A common mistake I see is organizations focusing on metrics without a clear action plan. Instead of just looking at a metric like PR cycle times, the goal should be to first identify the problem you're trying to solve. If the problem is poor code quality, then improving the review cycle times might help, but only because it’s part of a larger process of improving quality, not just for the sake of improving the metric.
It’s also essential to approach this with an experimentation mindset. For example, start by identifying an area for improvement, make a hypothesis about how to improve it, then test it and use engineering insights data to see if your hypothesis is correct. Starting with a metric and trying to manipulate it is a quick way to lose sight of your larger purpose.
Step 4: Program and Rollout Strategy
The next piece of the puzzle is your program and rollout strategy. It’s easy to roll out an engineering insights platform and expect people to just log in and start using it, but that’s not enough. You need to think about how you'll introduce this new tool to the various stakeholders across different teams and business units.
The key here is to design a value loop within a smaller team or department first. Get a team to go through the full cycle of seeing the insights, taking action, and then quantifying the impact of that action. Once you've done this on a smaller scale, you can share success stories and roll it out more broadly across the organization. It’s not about whether people are logging into the platform—it’s about whether they’re driving meaningful change based on the insights.
Step 5: Choose Your Platform Wisely
And finally, we come to the platform itself. It’s the shiny object that many organizations focus on first, but as I’ve said before, it’s the last piece of the puzzle, not the first. Engineering insights platforms like Code Climate are powerful tools, but they can’t solve the problem of a poorly defined strategy.
I’ve seen organizations spend months evaluating these platforms, only to realize they didn't even know what they needed. One company in the telecom industry realized that no available platform suited their needs, so they chose to build their own. The key takeaway here is that your platform should align with your strategy—not the other way around. You should understand your purpose, people, and process before you even begin evaluating platforms.
Looking Ahead
To build a successful engineering insights strategy, you need to go beyond just installing a tool. An insights platform can only work if it’s supported by a clear purpose, the right people, a well-defined process, and a program that rolls it out effectively. The combination of these elements will ensure that your insights platform isn’t just a dashboard—it becomes a powerful driver of change and improvement in your organization.
Remember, a successful software engineering insights strategy isn’t just about the tool. It’s about building a culture of data-driven decision-making, fostering continuous improvement, and aligning all your teams toward achieving business outcomes. When you get that right, the value of engineering insights becomes clear.
Want to build a tailored engineering insights strategy for your enterprise organization? Get expert recommendations at our free insights strategy workshop. Register here.
Andrew Gassen has guided Fortune 500 companies and large government agencies through complex digital transformations. He specializes in embedding data-driven, experiment-led approaches within enterprise environments, helping organizations build a culture of continuous improvement and thrive in a rapidly evolving world.
Most organizations are great at communicating product releases—but rarely do the same for process improvements that enable those releases. This is a missed opportunity for any leader wanting to expand “growth mindset,” as curiosity and innovation is as critical for process improvement as it is product development.
Curiosity and innovation aren’t limited to product development. They’re just as essential in how your teams deliver that product. When engineering and delivery leaders share what they’re doing to find efficiencies and unclog bottlenecks, they not only improve Time to Value — they help their peers level up too.
Create Buzz Around Process Wins
Below is a template leaders can use via email or communication app (Slack, Microsoft Teams) to share process changes with their team. I’ve personally seen updates like this generate the same level of energy as product announcements—complete with clap emojis👏 and follow-up pings like “Tell me more!” Even better, they’re useful for performance reviews and make great resume material for the leads who author them (excluding any sensitive or proprietary content, of course).
Subject: [Experiment update]
[Date]
Experiment Lead: [Name]
Goal: [Enter the longer term goal your experiment was in service of]
Opportunity: [Describe a bottleneck or opportunity you identified for some focused improvement]
Problem: [Describe the specific problem you aimed to solve]
Solution: [Describe the very specific solution you tested]
Metric(s): [What was the one metric you determined would help you know if your solution solved the problem? Were there any additional metrics you kept track of, to understand how they changed as well?]
Action: [Describe, in brief, what you did to get the result]
Result: [What was the result of the experiment, in terms of the above metrics?]
Next Step: [What will you do now? Will you run another experiment like this, design a new one, or will you rollout the solution more broadly?]
Key Learnings: [What did you learn during this experiment that is going to make your next action stronger?]
Please reach out to [experiment lead’s name] for more detail.
Sample Use Case
Subject: PR Descriptions Boost Review Speed by 30%
March 31, 2025
Experiment Lead: Mary O’Clary
Goal: We must pull a major capability from Q4 2024 into Q2 2025 to increase our revenue. We believe we can do this by improving productivity by 30%.
Opportunity: We found lack of clear descriptions were a primary cause of churn & delay during the review cycle. How might we improve PR descriptions, with information reviewers need?
Problem: Help PR Reviewers more regularly understand the scope of PRs, so they don’t need to ask developers a bunch of questions.
Solution: Issue simple guidelines for what we are looking for PR descriptions
Metric(s): PR Review Speed. We also monitored overall PR Cycle Time, assuming it would also improve for PRs closed within our experiment timeframe.
Action: We ran this experiment over one 2 week sprint, with no substantial changes in complexity of work or composition of the team. We kept the timeframe tight to help eliminate additional variables.
Result: We saw PR Review Speed increase by 30%
Next Step: Because of such a great result and low perceived risk, we will roll this out across Engineering and continue to monitor both PR Review Speed & PR Cycle Time.
Key Learnings: Clear, consistent PR descriptions reduce reviewer friction without adding developer overhead, giving us confidence to expand this practice org-wide to help accelerate key Q2 2025 delivery.
Please reach out to Mary for more detail.
How Make This Process Stick
My recommendation is to appoint one “editor in chief” to issue these updates each week. They should CC the experiment lead on the communication to provide visibility. In the first 4-6 weeks, this editor may need to actively solicit reports and coach people on what to share. This is normal—you’re building a new behavior. During that time, it's critical that managers respond to these updates with kudos and support, and they may need to be prompted to do so in the first couple of weeks.
If these updates become a regular ritual, within ~3 months, you’ll likely have more contributions than you can keep up with. That’s when the real cultural shift happens: people start sharing without prompting, and process improvement becomes part of how your org operates.
I’ve seen this work in large-scale organizations, from manufacturing to healthcare. Whether your continuous improvement culture is just getting started or already mature, this small practice can help you sustain momentum and deepen your culture of learning.
Give it a shot, and don’t forget to celebrate the wins along the way.
Jen Handler is the Head of Professional Services at Code Climate. She’s an experienced technology leader with 20 years of building teams that deliver outcome-driven products for Fortune 50 companies across industries including healthcare, hospitality, retail, and finance. Her specialties include goal development, lean experimentation, and behavior change.
Output is not the same as impact. Flow is not the same as effectiveness. Most of us would agree with these statements—so why does the software industry default to output and flow metrics when measuring success? It’s a complex issue with multiple factors, but the elephant in the room is this: mapping engineering insights to meaningful business impact is far more challenging than measuring developer output or workflow efficiency.
Ideally, data should inform decisions. The problem arises when the wrong data is used to diagnose a problem that isn’t the real issue. Using misaligned metrics leads to misguided decisions, and unfortunately, we see this happen across engineering organizations of all sizes. While many companies have adopted Software Engineering Intelligence (SEI) platforms—whether through homegrown solutions or by partnering with company that specializes in SEI like Code Climate—a clear divide has emerged. Successful and mature organizations leverage engineering insights to drive real improvements, while others collect data without extracting real value—or worse, make decisions aimed solely at improving a metric rather than solving a real business challenge.
From our experience partnering with large enterprises with complex structures and over 1,000 engineers, we’ve identified three key factors that set high-performing engineering organizations apart.
1. Treating Software Engineering Insights as a Product
When platform engineering first emerged, early innovators adopted the mantra of “platform as a product” to emphasize the key principles that drive successful platform teams. The same mindset applies to Software Engineering Intelligence (SEI). Enterprise organizations succeed when they treat engineering insights as a product rather than just a reporting tool.
Data shouldn’t be collected for the sake of having it—it should serve a clear purpose: helping specific users achieve specific outcomes. Whether for engineering leadership, product teams, or executive stakeholders, high-performing organizations ensure that engineering insights are:
- Relevant – Focused on what each audience actually needs to know.
- Actionable – Providing clear next steps, not just numbers.
- Timely – Delivered at the right moment to drive decisions.
Rather than relying on pre-built dashboards with generic engineering metrics, mature organizations customize reporting to align with team priorities and business objectives.
For example, one of our healthcare customers is evaluating how AI coding tools like GitHub Copilot and Cursor might impact their hiring plans for the year. They have specific questions to answer and are running highly tailored experiments, making a custom dashboard essential for generating meaningful, relevant insights. With many SEI solutions, they would have to externalize data into another system or piece together information from multiple pages, increasing overhead and slowing down decision-making.
High-performing enterprise organizations don’t treat their SEI solution as static. Team structures evolve, business priorities shift, and engineering workflows change. Instead of relying on one-size-fits-all reporting, they continuously refine their insights to keep them aligned with business and engineering goals. Frequent iteration isn’t a flaw—it’s a necessary feature, and the best organizations design their SEI operations with this in mind.
2. The Value of Code is Not the Code
Many software engineering organizations focus primarily on code-related metrics, but writing code is just one small piece of the larger business value stream—and rarely the area with the greatest opportunities for improvement. Optimizing code creation can create a false sense of progress at best and, at worst, introduce unintended bottlenecks that negatively impact the broader system.
High-performing engineering organizations recognize this risk and instead measure the effectiveness of the entire system when evaluating the impact of changes and decisions. Instead of focusing solely on PR cycle time or commit activity, top-performing teams assess the entire journey:
- Idea generation – How long does it take to move from concept to development?
- Development process – Are teams working efficiently? Are bottlenecks slowing down releases?
- Deployment & adoption – Once shipped, how quickly is the feature adopted by users?
- Business outcomes – Did the feature drive revenue, retention, or efficiency improvements?
For example, reducing code review time by a few hours may seem like an efficiency win, but if completed code sits for six weeks before deployment, that improvement has little real impact. While this may sound intuitive, in practice, it’s far more complicated—especially in matrixed or hierarchical organizations, where different teams own different parts of the system. In these environments, it’s often difficult, though not impossible, for one group to influence or improve a process owned by another.
One of our customers, a major media brand, had excellent coding metrics yet still struggled to meet sprint goals. While they were delivering work at the expected rate and prioritizing the right items, the perception of “failed sprints” persisted, creating tension for engineering leadership. After further analysis, we uncovered a critical misalignment: work was being added to team backlogs after sprints had already started, without removing any of the previously committed tasks. This shift in scope wasn’t due to engineering inefficiency—it stemmed from the business analysts' prioritization sessions occurring after sprint commitments were made. A simple rescheduling of prioritization ceremonies—ensuring that business decisions were finalized before engineering teams committed to sprint goals. This small yet system-wide adjustment significantly improved delivery consistency and alignment—something that wouldn’t have been possible without examining the entire end-to-end process.
3. Shifting from Tactical Metrics to Strategy
There are many frameworks, methodologies, and metrics often referenced as critical to the engineering insights conversation. While these can be useful, they are not inherently valuable on their own. Why? Because it all comes down to strategy. Focusing on managing a specific engineering metric or framework (i.e. DORA or SPACE) is missing the forest for the trees. Our most successful customers have a clear, defined, and well-communicated strategy for their software engineering insights program—one that doesn’t focus on metrics by name. Why? Because unless a metric is mapped to something meaningful to the business, it lacks the context to be impactful.
Strategic engineering leaders at large organizations focus on business-driven questions, such as:
- Is this engineering investment improving customer experience?
- Are we accelerating revenue growth?
- Is this new approach or tool improving cross-functional collaboration?
Tracking software engineering metrics like cycle time, PR size, or deployment frequency can be useful indicators, but they are output metrics—not impact metrics. Mature organizations go beyond reporting engineering speed and instead ask: "Did this speed up product releases in a way that drove revenue?"
While challenging to measure, this is where true business value lies. A 10% improvement in cycle time may indicate progress, but if sales remain flat, did it actually move the needle? Instead of optimizing isolated metrics, engineering leaders should align their focus with overarching business strategy. If an engineering metric doesn’t directly map to a key strategic imperative, it’s worth reevaluating whether it’s the right thing to measure.
One of our retail customers accelerated the release of a new digital capability, allowing them to capture additional revenue a full quarter earlier than anticipated. Not only did this directly increase revenue, but the extended timeline of revenue generation created a long-term financial impact—a result that finance teams, investors, and the board highly valued. The team was able to trace their decisions back to insights derived from their engineering data, proving the direct connection between software delivery and business success.
Understanding the broader business strategy isn’t optional for high-performing engineering organizations—it’s a fundamental requirement. Through our developer experience surveys, we’ve observed a significant difference between the highest-performing organizations and the rest as it relates to how well developers understand the business impact they are responsible for delivering. Organizations that treat engineers as task-takers, isolated from business impact, consistently underperform—even if their coding efficiency is exceptional. The engineering leaders at top-performing organizations prioritize alignment with strategy and avoid the distraction of tactical metrics that fail to connect to meaningful business outcomes.
Learn how to shift from micro engineering adjustments to strategic business impact. Request a Code Climate Diagnostic.
Code Climate has supported thousands of engineering teams of all sizes over the past decade, enhancing team health, advancing DevOps practices, and providing visibility into engineering processes. According to Gartner®, the Software Engineering Intelligence (SEI) platform market is expanding as engineering leaders increasingly leverage these platforms to enhance productivity and drive business value. As pioneers in the SEI space, the Code Climate team has identified three key takeaways from partnerships with our Fortune 100 customers:
- Engineering Metrics Are Not Enough
- Engineering leaders that adopt a Software Engineering Intelligence (SEI) platform without a proper SEI strategy fail to extract value from the data
- Engineering leaders that adopt quantitative metrics without qualitative measures are missing the full picture
- Engineering leaders that adopt a Software Engineering Intelligence (SEI) platform without a proper SEI strategy fail to extract value from the data
- Hands-Off Approach Falls Short
- Approaching an SEI platform as a traditional turnkey SaaS product does not ensure team success
- Organizations that lack collaboration with an SEI solutions provider often struggle to drive adoption and understanding of engineering insights
- Approaching an SEI platform as a traditional turnkey SaaS product does not ensure team success
- Insights Alone Do Not Drive Outcomes
- Engineering leaders often struggle to translate insights from an SEI platform into actionable steps
- Engineering leaders often struggle to align engineering performance to meaningful business outcomes
- Engineering leaders often struggle to translate insights from an SEI platform into actionable steps
Empowering Engineering Leaders at Enterprise Organizations
The above takeaways have prompted a strategic shift in Code Climate’s roadmap, now centered on enterprise organizations with complex engineering team structure and workflows. As part of this transition, our flagship Software Engineering Intelligence (SEI) platform, Velocity, is now replaced by an enhanced SEI platform, custom-designed for each leader and their organization. With enterprise-level scalability, Code Climate provides senior engineering leaders complete autonomy over their SEI platform, seamlessly integrating into their workflows while delivering the customization, flexibility, and reliability needed to tackle business challenges.
Moreover, we understand that quantitative metrics from a data platform alone cannot transform an organization, which is why Code Climate is now a Software Engineering Intelligence Solutions Partner—offering five key characteristics that define our approach
- Tailored Solutions: We provide engineering solutions via quantitative insights and qualitative workshops that are specifically designed to meet the unique needs of enterprise engineering teams—moving beyond standard, black-box solutions.
- Strategic Collaboration: We enable our enterprise customers to build an SEI strategy, engaging with key stakeholders to align Code Climate’s solution and services with their broader business goals.
- Long-Term Partnership: Our strategic partnership with our enterprise customers is typically ongoing, focusing on long-term value rather than offering a standard insights platform. As an enterprise-level SEI solutions partner, we are invested in the sustained success of our customers.
- Expert Guidance: We offer expert guidance and actionable recommendations to help our enterprise customers navigate challenges, optimize performance, and achieve business goals.
- End-to-End Support: We provide comprehensive services, from advisory support and implementation to ongoing support and optimization.
A Message from the New CEO of Code Climate
"During my time at Pivotal Software, Inc., I met with hundreds of engineering executives who consistently asked, “How do I improve my software engineering organization?” These conversations revealed a universal challenge: aligning engineering efforts with business goals. I joined Code Climate because I'm passionate about helping enterprise organizations address these critical questions with actionable insights and data-driven strategies that empower engineering executives to drive meaningful change." - Josh Knowles, CEO of Code Climate
Ready to make data-driven engineering decisions to maximize business impact? Request a consultation.
Today, we’re excited to share that Code Climate Quality has been spun out into a new company: Qlty Software. Code Climate is now focused entirely on its next phase of Velocity, our Software Engineering Intelligence (SEI) solution for enterprise organizations
How It Started
I founded Code Climate in 2011 to help engineering teams level up with data. Our initial Quality product was a pioneer for automated code review, helping developers merge with confidence by bringing maintainability and code coverage metrics into the developer workflow.
Our second product, Velocity, was launched in 2018 as the first Software Engineering Intelligence (SEI) platform to deliver insights about the people and processes in the end-to-end software development lifecycle.
All the while, we’ve been changing the way modern software gets built. Quality is reviewing code written by tens of thousands of engineers, and Velocity is helping Fortune 500 companies drive engineering transformation as they adopt AI-enabled workflows.
Today, Quality and Velocity serve different types of software engineering organizations, and we are investing heavily in each product for their respective customers.
Where We're Going
To serve both groups better, we’re branching out into two companies. We’re thrilled to introduce Qlty Software, and to focus Code Climate on software engineering intelligence.
Over the past year, we’ve made more significant upgrades to Quality and our SEI platform, Velocity, than ever before. Much of that is limited early access, and we’ll have a lot to share publicly soon. As separate companies, each can double down on their products.
Qlty Software is dedicated to taking the toil out of code maintenance. The new company name represents our commitment to code quality. We’ve launched a new domain, with a brand new, enhanced edition of the Quality product.
I’m excited to be personally moving into the CEO role of Qlty Software to lead this effort. Josh Knowles, Code Climate’s General Manager, will take on the role of CEO of Code Climate, guiding the next chapter as an SEI solutions partner for technology leaders at large, complex organizations.
We believe the future of developer tools to review and improve code automatically is brighter than ever – from command line tools accelerating feedback loops to new, AI-powered workflows – and we’re excited to be on that journey with you.
-Bryan
CEO, Qlty Software
Technology is evolving very quickly but I don't believe it's evolving as quickly as expectations for it. This has become increasingly apparent to me as I've engaged in conversations with Code Climate's customers, who are senior software engineering leaders across different organizations. While the technology itself is advancing rapidly, the expectations placed on it are evolving at an even faster pace, possibly twice as quickly.
New Technology: AI, No-Code/Low-Code, and SEI Platforms
There's Generative AI, such as Copilot, the No-code/Low-code space, and the concept of Software Engineering Intelligence (SEI) platforms, as coined by Gartner®. The promises associated with these tools seem straightforward:
- Generative AI aims to accelerate, improve quality, and reduce costs.
- No-code and Low-code platforms promise faster and cheaper software development accessible to anyone.
- SEI platforms such as Code Climate enhance productivity measurement for informed decisions leading to faster, efficient, and higher-quality outcomes.
However, the reality isn’t as straightforward as the messaging may seem:
- Adopting Generative AI alone can lead to building the wrong things faster.
- No-code or Low-code tools are efficient until you hit inherent limitations, forcing cumbersome workarounds that reduce maintainability and create new challenges compared to native code development.
- As for SEI platforms, as we've observed with our customers, simply displaying data isn't effective if you lack the strategies to leverage it.
When I joined Code Climate a year ago, one recurring question from our customers was, "We see our data, but what's the actionable next step?" While the potential of these technologies is compelling, it's critical to address and understand their practical implications. Often, business or non-technical stakeholders embrace the promises while engineering leaders, responsible for implementation, grapple with the complex realities.
Navigating New Technology Expectations and Realities
Software engineering leaders now face increased pressure to achieve more with fewer resources, often under metrics that oversimplify their complex responsibilities. It's no secret that widespread layoffs have affected the technology industry in recent years. Despite this, the scope of their responsibilities and the outcomes expected from them by the business haven't diminished. In fact, with the adoption of new technologies, these expectations have only increased.
Viewing software development solely in terms of the number of features produced overlooks critical aspects such as technical debt or the routine maintenance necessary to keep operations running smoothly. Adding to that, engineering leaders are increasingly pressured to solve non-engineering challenges within their domains. This disconnect between technical solutions and non-technical issues highlights a fundamental gap that can't be bridged by engineering alone—it requires buy-in and understanding from all stakeholders involved.
This tension isn't new, but it's becoming front-and-center thanks to the promises of new technologies mentioned above. These promises create higher expectations for business leaders, which, in turn, trickle down to engineering leaders who are expected to navigate these challenges, which trickle down to the teams doing the work. Recently, I had a conversation with a Code Climate customer undergoing a significant adoption of GitHub Copilot, a powerful tool. This particular leader’s finance team told her, "We bought this new tool six months ago and you don't seem to be operating any better. What's going on?" This scenario reflects the challenges many large engineering organizations face.
Navigating New Technology Challenges and Taking Action
Here's how Code Climate is helping software engineering leaders take actionable steps to address challenges with new technology:
- Acknowledging the disconnect with non-technical stakeholders, fostering cross-functional alignment and realistic expectations. Facilitating open discussions between technology and business leaders, who may never have collaborated before, is crucial for progress.
- Clearly outlining the broader scope of engineering challenges beyond just writing code—evaluating processes like approval workflows, backlog management, and compliance mandates. This holistic view provides a foundation for informed discussions and solutions.
- Establishing a shared understanding and language for what constitutes a healthy engineering organization is essential.
In addition, we partner with our enterprise customers to experiment and assess the impact of new technologies. For instance, let's use the following experiment template to justify the adoption of Copilot:
We believe offering Copilot to _______ for [duration] will provide sufficient insights to inform our purchasing decision for a broader, organization-wide rollout.
We will know what our decision is if we see ______ increase/decrease.
Let’s fill in the blanks:
We believe offering Copilot to one portfolio of 5 teams for one quarter will provide sufficient insights to inform our purchasing decision for a broader, organization-wide rollout.
We will know what our decision is if we see:
- An increase in PR Throughput
- A decrease in Cycle Time
- No negative impact to Rework
- No negative impact to Defect Rate
Andrew Gassen leads Code Climate's enterprise customer organization, partnering with engineering leaders for organization-wide diagnostics to identify critical focus areas and provide customized solutions. Request a consultation to learn more.