Disconnect Between Developers and Software Engineering Leaders – Christina Forney, Uplevel

This is Techstrong tv. Hey guys, thanks for the throw. We're here with Christina Forney, who is vice President of Product for Uplevel, and we're talking about a new survey they have come out with, which may have some interesting findings for all of those that you have long suspected that there may be a disconnect between developers and DevOps teams and the rest of the organization.

Christina, welcome to the show. Thank you so much for having me. Walk us through the high points.

I think, you know, there's always been a lot of chatter about this, but I haven't seen anybody actually put some real data and some real research into this. So what did you guys find? Yeah, so why we wanted to think about this topic is we were hearing from our customers that engineering leaders were really disconnected.

They lacked, lacked visibility into what was really going on with their engineering teams and vice versa, that teams were really struggling to understand how their work leveled up into the most important business outcomes and the, um, most important initiatives that leaders were trying to get done in their organization. So we established this hypothesis of there is this massive disconnect. There is this thing going on, let's go get the data to validate that.

And so, um, our, our key takeaway, our biggest thing that you walk away with is that CTOs, engineering leaders really need to be better connected. They are operating on intuition for a vast majority of cases. And the reality is developers want to be measured.

They just wanna make sure those metrics matter. So, digging into the study a little bit more, um, the study was over 350 software developers, and we asked them what their views were on leadership's perception of their work. And so, um, what we were able to find is that, um, a third of developers think that engineering leaders are completely unaware of the roadblocks that they have in front of them, and they're not working to get those roadblocks fixed.

Um, and so there's this hard struggle where developers are really having trouble. There's things in their way and, and leaders just don't know what's going on. They don't know how to help and they don't really know what's needed.

Um, and, uh, on top of that, um, they're then making strategic decisions that aren't factoring in kind of these negative consequences. And, uh, we found in the study that 56% of developers surveyed believe that CTOs are making strategic decisions without really understanding those negative consequences. And 51% think c CTOs moving people around on different projects and different tasks, and they don't understand the implications of moving people around.

And what that, that effect can have on an organization Is that because we're kind of measuring the wrong things, I mean, DevOps teams, for example, might be obsessed with release times, but then the developers are more concerned about what is the overall productivity from them in terms of how much time they can spend in the zone writing code. So how do we get past this? Yeah, that's spot on.

So what we found is actually developers liked when they were tracked. They liked actually seeing that CTOs had the metrics. Um, and 88% of the respondents saw those tools as favorable for the organization.

Um, and that it helped support engineering leaders better understand what was going on. However, 91% of those same developers were really unhappy with what was actually being tracked, because often it doesn't have the full picture of what's going on within an organization. Uh, many of these tools focus on just what does the C T O want?

What does the C T O need? What are the leadership metrics that they need and aren't connecting the groups? And so at Uplevel our, our focus and the way that we're trying to solve this is by helping solve the challenge for the organization.

So wanting to connect those dots across the layers so that leaders can make more informed decisions about what matters most. And developers can understand how their work is contributing to the most impactful outcomes. And so the way that we're doing that, and what we saw in the survey lined right up to this is that they, developers really wish that, um, leaders are tracking more around the hours that are being worked to indicate burnout.

So 52% of our surveyed respondents really wanted to have data tracked around burnout and how they were doing and what it was taking to get their work done. And 49% wanted to showcase what is the work that I'm actually doing? What am I getting sucked into?

How am I spending my time? So allocation data was really important, but developers wanted these leaders to have a better clarity of us because often what we find is leaders have these top two, three initiatives that they think are most important for the business, but then they're not getting done and they don't understand why. And developers may not even know what those top initiatives are.

If communication is broken, or even if they do know what it is, maybe they're getting pulled into tons of customer support issues and to keep the lights on work is taking up 80, 90% of their time. Or maybe the organization has terrible meeting hygiene and they're stuck in meetings all the time. They're not getting their focus time, they're not getting the most important work done.

And so they're just not able to spend time on these initiatives. And by being able to look at that allocation data developers feel represented, this is what's really going on, this is really what's taking up my time. And leaders have a clearer picture into what's actually happening.

And then the third metric that developers really asked for in this survey was how much focus time they were getting. What is the amount of deep work time that they're getting? Are they getting enough time to truly get their work done?

And 46% of respondents felt that this was an important metric that they wished engineering leadership was measuring. Do you think that there are a lot of bottlenecks in this system that people aren't aware of, but the developers encounter and they just scratch their heads and suck it up, but they don't know why they're hitting this bottleneck? That's absolutely right.

Yeah. Um, and until you have the complete picture rather than just a small picture of what's going on across your organization, you really won't know what the most impactful bottleneck could be. So you need to understand, cause I kind of, we, we categorize them at uplevel in three different components, your people health.

So we talked about that. That's often what's most missing in metrics and measurement tools. Am I getting enough deep work time?

Am I trending towards burnout? Uh, am I working really late hours? My process, are we spending way too much time in meetings?

What are we actually working on? How are we working together? Um, and our operational metrics.

So what is our cycle time? How fast are we shipping? Um, you have to combine all of these different areas in order to truly what's happening.

And that's how, you know, you're addressing the most impacted bottleneck as the leader. Is this situation getting worse in the post covid era because the teams are more distributed than ever, so not everybody seems to know what everybody else is doing, and I don't think it's feasible to bring everybody back in the office. So how do we get some way to kinda get, gain the visibility we need without, you know, locking everybody in the same room?

Yeah. Um, I think it has exacerbated the problem. I think the move to more remote, more asynchronous, more distributed ways of working has highlighted, um, the inefficiencies and the disconnect and, uh, what's going on.

And I think, uh, where previously leaders would just walk around and could see what's happening on people's screens and they could kind of keep an eye on how many hours is this person spending in their seat going to a more distributed, more remote kind of way of working is now forcing leaders to have to look at the outcomes that are being produced. And, um, that's really hard to do. And, um, if you don't look at the outcomes, what you're then measuring on is, um, how many hours am I working?

And that's not necessarily a good representation of value and impact to the business. Mm-hmm. As part of this whole conversation too, the leaders will kind of assume that if the developers are hitting some sort of bottleneck, that they'll raise their hand and say, Hey, there's an issue here.

But that doesn't always happen. And different kinds of people are not necessarily inclined cuz maybe they don't wanna be perceived as not knowing enough about their job as they should, or they just don't think that anybody's gonna listen to 'em. So how do we kinda, you know, get it to the point where somebody does feel comfortable raising their hands saying, Hey, I've got an issue here.

Yeah. Well that's where tools like the Uplevel or other engineering intelligence platforms can surface what's really going on. It allows you to create more of a shared understanding.

One of the most important things that we drive within organizations is better conversations. We highlight what needs to get talked about and we are advocating for the developers in what is slowing them down and how can they work more effectively, more efficiently, um, removing those bottlenecks from from their ways of working. And sometimes just by showing the data, you start to create more of a willingness to talk about the problem, because then there's, um, it's grounded in fact of data rather than feelings.

And sometimes feelings are really hard. I, I have heard many, many times where, um, uh, you know, the question often gets asked me, what is your team doing? Why are they doing this?

Why aren't you getting these things done? And it's kind of grounded in mistrust because there's lack of visibility. And um, and then sometimes that same person asking those questions has some sort of assumption or assertion that they believe to be true.

And you as a leader of a team or a team manager may disagree with that assertion and you don't have the data back to back it up. And now it's intuition versus intuition and you're just gonna have a really fraught argument and a fraught, uh, communicate. Like you just won't be able to get to the heart of what's really going on so that you're talking about the real problem and the real root cause and the r reality of what's happening versus what the perception is that's happening.

A lot of the data that we need is already in the tools someplace, and a lot of folks are trying to, um, reenter data into a project management application to kind of track all this stuff down. But that doesn't seem very realistic either. So, um, do we need to just get to a, uh, an automated system somehow or other where, you know, some actual fact-based data starts to surface and that becomes actionable intelligence?

Yeah, that's spot on. Um, because otherwise what we see is leaders are going and having meetings or having conversations, and actually this was part of the survey that we had, is how, how were leaders getting this information if they weren't using tools? Um, and 57% of our respondents said they're using meetings or live conversations to gather data, which again, becomes anecdotal based on who you've talked to.

Um, 53% were relying on messages or emails and 46% were trying to send out surveys to their own teams, uh, to understand what was going on. And so it's just a very manual, very tedious process. And on top of that, maybe you have leaders who are writing their own scripts or, uh, writing their own queries to gather data themselves, but it's inconsistent because one manager may write a a set of scripts one way and another manager might set write a set of scripts another way, and it's not gonna be consistent across those teams.

And so you're comparing apples to oranges and it isn't a clear like way of talking about what's going on. And so by having a, an intelligence platform that can give you these insights in a consistent way, um, you really get a lot more power from that. Um, and especially when you have a platform who's spent a lot of time doing this.

So at Uplevel we're using machine learning as well as the ana, uh, analytics prior best practices to combine, like where I work every day, my code, my project, tracking, my calendar, how I communicate in Slack. Um, and we combine all of that into really smart models to represent what's truly going on in the work. Is there a cultural disconnect here?

A lot of the people who are running these engineer teams were around before we had these kind of tools, so they're basically of the, you know, suck it up buttercup mindset. Um, is there some way to kind of bring them along and say, Hey guys, there's just a better way of thinking about this? Yeah, I think you see that in the results, um, when you can make a better decision because you really know what's going on when you can better help support your teams, um, you create a better culture for the engineers within your organization and you create better outcomes for your business.

So hopefully the results can drive that change. Was there anything in the survey that kind of surprised you, basically, you know, besides the big giant takeaway, but was there any nugget in there that you went, wow, I didn't think that would be the case. I really did not expect that high of a percentage of developers to really want to be tracked as much as they could.

I mean, I I, I often have encountered developers and having been a developer myself in my past, um, tools like this are often, um, perceived with a lot of mistrust, um, and suspicion. And so being able to survey and understand that there was a craving for it, and maybe, yes, a lot of tools are mistrusted, but it's because the insights that they're showcasing aren't ones that I trust or aren't ones that I think are good. I think at this point in time it's pretty well known that you don't wanna track lines of code because that just drives really poor behavior and really poor code quality kind of assessments versus understanding more comprehensively like, how are we shipping together?

What is our velocity? What is our productivity? Um, so yeah, I was, I was most surprised in seeing how many developers really did want to be tracked, um, and how important it was for them to know that these metrics were really telling the whole story and really providing all of the context needed.

All right. Cool. Folks, you're heard in here, the elephant in the room has a name.

It's called Developer Productivity, and we need to have a conversation about it. Christina, thanks for being on the show. Yeah, thanks so much.

All right. Back to you guys in the.