Tempo CSO Shannon Mason on Bringing Order to Chaotic Software Engineering Workflows

Well, software development, chaos. I think it's not much of a secret. We know it exists.

And question is, is it gonna get any better or maybe worse? Shannon, welcome to the show. Thanks, Mike.

Glad to be here. And, uh, glad to talk on one of my favorite, not so favorite subjects. I think that might be true for everybody involved in software development.

So let's just jump into it. 'cause it's one of those dirty little secrets about how we build software. It's complex, it's chaos, and sometimes it's more art and luck than it is science.

But anyway, let's jump in here and say in your mind, what is the current state of software development and what kind of ais Um, wow, you, you, you made me think of. Uh, it's better to be, uh, good than, uh, and lucky than, uh, than great, right? Um, but, uh, one of the things that I think we're really faced with right now, I, I don't think we can get through.

Mike. You probably haven't had any conversations without talking about ai. Um, so for me it's this combination of, um, a lot of really wonderful, great engineers trying to figure out how do I incorporate this into my daily life?

These massive pushes from, um, executive leadership, which oftentimes we might talk a lot about execs today because a lot of chaos usually starts to originate up, up in that area in those ways. If it's not the market, it's usually some sort of internal chaos coming in and saying, Hey, we need to start investing in this area. We need to start, you know, improving productivity, improving speed.

We need to start doing these things. And we're starting to see, I think some of the results or some of the data now that there's been enough information, um, enough utilization, and it's showing us that, uh, it's actually increasing a little bit of chaos if you're not thinking about it smartly. So I think a lot of engineers right now are, um, both struggling with the continuous requirement to innovate, develop, maintain, and also the speed of which new technologies are coming in, which has been ever faster.

And then you have this added component of ai. So, um, the landscape, at least as I've seen in the last, especially the last year, has changed dramatically. Um, over at Tempo.

We're trying to look at even studies and how those studies relate to our own in internal transformation efforts. So like Cornell did a long term study for this year. I think long term is probably a little bit too, um, too gracious.

But they've been looking at and published a study just looking at whether or not the productivity speeds and gains that are expected from incorporating AI into your engineering organization. Are there. Um, short, long story short, uh, not so much when it's a complex code base and the more, uh, mature your engineers are, it actually actually detracts from their productivity.

It takes time away. Um, which I don't think if you spoke with any dev, they'd say it's anything differently. Um, so new code bases works great.

Um, younger engineers works wonderful or new, and career engineers works wonderful. Um, but the more mature and the larger and more complex or code is the more potentially detrimental it can be, especially from a security standpoint. And then yesterday there was even the report coming at an MIT from Nanda around, um, 95% of transformation efforts that are associated to AI and engineering are not seeing the success rates that they're looking for right now.

So we've got this like big, you know, push that's coming into organizations, but still software engineers need to build beautiful products, wonderful products. And so there's this kind of clash that's occurring, um, that's really I think a new, a new horizon for us, uh, in development. I also hear that folks are saying that the code generated by the AI platforms is, shall we say, verbose.

And when they go in and try to fix it and debug it, well they don't know how it was constructed in the first place. So they're kind of scratching their heads and saying, I might've been better off if I just wrote this thing from scratch myself. Anyway.

Yeah, and I think that that kind of connects back to what we're seeing in terms of studies. I mean, I love that there are people out there who spend their days researching this, you know, not just us using it. Um, it's one of the things that I love, you know, having a background in psychology, that there are people out there who spend all their days looking at organizational psychology and how orgs do planning and things like that.

But you're exactly right, right? Um, uh, there was a great, uh, webcast a few months back, uh, from Anthropic, you know, it's Claude. And um, and they said, you, you gotta think about this as having like the world's smartest intern sitting next to you.

But they need to be bounded and they need to be guided. And I think a lot of us are still in the place where we think of, uh, you know, adding maybe age agentic development or even age agentic networks, and that those things are just going to be continuously self-learning, continuously evolving, but they're not quite there yet. Um, and they can run a little bit rampant because they're just smart enough.

And so they'll go through and make changes. So I think to your earlier question, right, like that, that can add a lot of work. 'cause then you're double checking.

You wanna make sure that you're not potentially inserting code that exposes you. Um, I know that GI had, GitHub had a little bit of a, an issue around that. Um, and those sorts of things I think are really changing the dynamics for engineers where, you know, 10 years ago we were just thinking about how fast can we deploy to production and how fast can we make sure that we're running through all the checks and balances predeep to production.

And now it's like we've got all this other additional added complexity. And then of course, the inherent marketplace speed factor that's coming in from your leadership from, you know, other product companies saying like, you gotta move fast, you gotta move fast. Oh my gosh, everything's gonna go move so fast.

So, uh, it's definitely a wild ride right now. So under the heading of, I'm not sure whether I should laugh or cry, but, um, we are talking about citizen developers giving them vibe coding tools, and they're gonna have AI and they're gonna create software and it's gonna be rapidly iterated in the best of all possible world. Some professional developer might help them vet that thing and craft it.

And we will build more software than ever. Now in my low-code, no-code experience. Most of the applications that are built are well kind of ugly.

They're not very secure and they don't ever scale. So how are we gonna do this with, you know, when we change the definition of what an application developer is and all this stuff is supposed to come down to the DevOps pipelines and engineers who are already overwhelmed and maybe hopefully have a bunch of AI agents to help them manage this. Or how does this, in your mind, can this work?

Yeah, I, I absolutely think so. I think, um, what we're seeing right now is obviously a lot of early adoption and, and we'll go through the normal hype cycle with that, right? There'll be the trough of disillusionment I think will happen more, more quickly than we're we're used to, just because the speed at which these things can change.

Like, uh, that Cornell study that I mentioned that was from the beginning of the year, those models have already improved since then and you get different outputs. Um, but really for me, the benefit here and, um, you know, being so deeply involved in software development, being married to an engineer, these sorts of things, they, uh, they do start to show productivity gains if you're training your team on how to leverage them effectively, right? So, um, for example, none of us is going to go use lovable to build an enterprise scale application, but it's a great tool to figure out whether or not something is or is not feasible to kind of play around with ideas to get really early feedback around potentially a net new concept with a customer.

Uh, but you're not gonna take that code and then immediately transform it into a publicly facing, you know, site and application and like launch monetization around it. You're gonna use that as kind of like that early analysis and that early validation, which I think is amazing because what that means is that we can save ourselves a lot of those additional steps that can then happen further down the line. 'cause a lot of the rework tends to be, oh, hey, we didn't confirm with the customer whether or not they liked this, or we tried this particular path and it turned out that it was a little bit wonky to go through this interaction.

Or the math looks weird, or how we can convey this sort of visualization is a little bit strange. So for me, the benefit is like if you are treating your agents like an intern, a very smart intern that's sitting alongside you, that you can kind of offload tedium to, that's great. Um, and I think we should even start, you know, even more simplistically, which is like going through and pulling in information about how progress against all of the work looks like, right?

We don't need to necessarily use this to do big giant development. We can offload the tasks that come in that are around like status updates and sharing information about progression with the folks that wanna know that information so that we can allow our teams to spend more time in the flow state and actually doing work. So I think like, you know, there's so many little easy things that we can knock off that actually increase the joy for an engineer by leveraging, you know, models, large language language models, a lot of the intelligence that's coming out.

But at the end of the day, um, we still kind of go back and I still kind of go back to the mythical man month, right? There's only so many hours in the day and we need to eat, we need to take time, we need to find a place where we can actually focus our brains. Um, and unless we're using and thinking about all of the tooling from that standpoint, and that's AI and everything, it becomes a distraction.

And every distraction, uh, takes us away from the core goal, which is to craft something amazing. To your point about that there's so many hours in the day and our brains have some limitations. Theoretically, we're gonna exponentially increase the number of application development projects we can simultaneously manage.

Well that sounds great, but in practice, I'm not sure that teams can do that and that they can manage that many projects simultaneously because there's only so much room in their brains. Yep. Yep.

And this hits on my background, of course, which is in psychology and neuroscience and the cost of context switching is already really well known in our current landscape, and we've seen that really increase just based off of the speed at which we can deliver. I mean, I remember, uh, shipping software on disks way back in the day, right? To our customers, uh, not at Tempo in a former live.

Um, and then, you know, and going through deployments that, you know, were once a month and then all of a sudden it just became faster and faster and faster, and our code bases became increasingly more complex, but also had a lot of checks and balances in them to make sure that, you know, we're delivering things that are of quality and are secure. Um, and you start adding to that, and you're right, eventually our ability to kind of just keep track of all those things, uh, reaches a limit, reaches a cognitive limit. Uh, and the speed and pace at which we've seen, you know, over the 18, 18 hundreds, 19 hundreds and now the two thousands, um, the speed at which technological change, there's some really interesting studies about the psychological ramifications of that, right?

There's only so much intake that we can do around change before our brains start to be like, there's too much happening, and then we actually default to being a little bit lazy, right? It's just occurring. We just kind of go with it because there's so much we can't keep up.

Um, and I think we see that in like a little bit of a microcosm in our organizations where, you know, you'll just start to see almost, uh, just, just exhaustion and exhaustion for folks that are actually, and I think of, um, developers and, and, and all of our folks that are actually building the magic as hand crafters, they end up getting exhausted. You know, there's just brain fatigue that occurs. And when we're fatigued, one of the things that happens is then we start to ear towards bad decisions.

So like, I've been reading a lot about, you know, like the, you know, 14 hour work cycles, you know, 20 hour work cycles, like this big push for like the, you know, seven day work week, or six, six hour nine hour work weeks, or six days, nine hours or something like that. Something crazy I was reading about a couple weeks ago, and I was like, that's a really great recipe for very bad decisions to occur as the brain becomes to more and more tired. So I think that's where you also see, not to tie it into our earlier discussion about AI agents, is that then people start to get lazy and they start accepting things because they're exhausted.

There's too many things to keep track of. Um, and then I think we'll probably feel a little bit of that just overabundance of applications because no code, low code citizen engineers, you know, I can come up with any sort of idea and I'll produce it. Um, but I also wanna look at the flip side of that, which is, it's an amazing democratization of ability.

So folks that, you know, might not have had access to the best schools, the best opportunities perhaps, but have really great ideas who might have been locked into jobs because they need healthcare and, you know, maybe they don't come from generational wealth and their parents are gonna give them seed money to start doing something. They have that ability now to actually build out things and, and concepts and test them. So I think there's, uh, there's two sides of this.

Like we'll see a lot, um, you know, we hope that the markets balance themselves. Um, but I think, you know, what we'll see is, is more opportunity for folks that, um, might not have all the access that they're, that they're, um, historically we've been used to. But yeah, I do worry about just like so much information coming in.

Um, and I also worry about just the general idea of learning. Like learning is fun. Um, and sometimes we can, I think, be a little bit lazy if we're overwhelmed.

So you have a background in psychology or all these things related. I mean, people, again, they get frustrated and then they get angry and then they head off to the pub and they make all kinds of series of bad decisions that have nothing to do with it. But it all is somewhat related.

I I hope it's not, it's not that dire. Um, but it does happen, right? Um, and then, you know, the younger we are, the less fully developed our prefrontal cortex, uh, is in general.

And, um, and so the worst the decisions we make tend to be. Um, but I, I, you know, it's, there's a lot of input and there's a limit to how much input we can manage as humans. Um, and then you add on top of that just, you know, living in cultures that require a lot of time outside of work.

You have kids, you have family, you have a life, you have all these other things that are going on, maybe, you know, things are going on in your life that require your attention. Um, and so I'll, I'll kind of come back to thinking about, um, even in our organizations, if we're dealing with chaos or it feels like chaos, where can we offload the TDM to something that is intelligent and then taking a step back and adding focus, right? There's only so many things that a team can manage.

I think the, you know, like the Poppen d***s showed a few years back and this data continues to, to kind of maintain its stability over time. Like the, regardless of the organization size, like any, any team, any team of size two can only handle about two things or two projects, um, two ongoing activities before they start to get challenged. Um, so then we start to get this incremental decrease in productivity and this really big existential cost associated to it that can be tracked realistically.

Um, which is I think actually a great opportunity to bring your CFOs and your CEOs into the conversation is that like you do pay an opportunity cost by overburdening your teams with tedium by overburdening them with too much work, with overburdening them, with, with too much context shifting associated to too many projects. And so the adage is true, like, do one thing do really well, move on to the next thing is usually faster than doing five things simultaneously. Go figure.

Hmm. So there is a pet peeve that everybody has that you might be able to help with a little bit. But one of the things that occurs is we do have too many projects and we have all these balls in the air and we're trying to juggle all that stuff.

And somebody sends over an email, says, you know, Hey buddy, can you update that project management spreadsheet? And everybody's like, oh, I gotta go enter data, I gotta look all this stuff up. Is there some way to automate that whole thing?

Because if you talk to a software engineer, they kinda look at those project management people and they say, all the data's already in the tools I have. Can't you just see that yourself? Yeah.

Right. And that's, um, I mean, that's near and dear to my heart too. At Tempo, we got our start in time tracking, uh, which tends to be the bane of an engineer's existence, which is why we've spent a lot of time figuring out ways to both automate it.

Last year we actually launched an intelligent way to track, um, and add in like just the, the knowing where people are spending time and effort based off of their source code management systems based off of how they're leveraging their ides. All, like, all this stuff can kind of be observed and shared without having to ping somebody. Um, although, you know, with Slack, with all with Microsoft teams, people love pinging people.

Um, so I think, you know, to your point, those are the sorts of things that we should definitely look at automating. Um, now the hard part then becomes all of the hidden work that people might be hiding, right? Like, uh, you mentioned you get pings, you get an email that says like, Hey, can you, can you do this?

A lot of time that stuff doesn't get tracked. So for me, one of the biggest things that we can do, um, as an organization, especially as an engineering organization, product development organization, is make work visible. Even if it's just a quick, like, Hey, this is happening.

A lot of the systems that are out there, it's pretty easy to generate a little bit of a record. That effort is going somewhere. 'cause if we have that data, then we can start looking at the economic costs associated to adding in all of this additional work or all of that hidden work that we're may not be accounting for.

If you're working in an organization where making work visible is something that's frowned upon, that's usually a pretty good sign that the culture's not so great. Uh, and you're probably gonna get burnt out eventually anyways in that particular scenario. So, um, but those are the sorts of things that, that kind of have stuck with me over my time.

Um, in tech is just like, we have to make things visible. It's really hard to shift things if we don't have data. There's great systems out there.

I mean, tempo included, right? That will track these things, that will understand these things with as little friction as possible for the, the folks that are building the beautifulness. Um, and that's on purpose, right?

Because we wanna stay in that flow state. We wanna stay focused, we wanna allow people to stay focused. However, if we don't know that these things are happening becomes increasingly difficult to, um, to make sure that we can change them.

Mm-hmm. What's your best advice to people? And I'm gonna ask this for one little caveat in the middle of that, because, you know, sometimes, you know, I'll talk to people and I'll say, well, what we're gonna do is, you know, require everybody to have some downtime and they get more aggravated.

'cause now they're forced to have downtime. Yeah. Right?

Um, you know what, one of the, one of the, I think the, the nicest things that we can do is, um, actually declare a no meeting day. Simple, simple technique, simple activity, just a day that is about focus, the full focus day, whatever you wanna call it. Um, build some kind of pomp and circumstance.

This is something that also needs to be followed by your leadership too, right? It's one of those things where it's just like your leadership says like, Hey, we love vacations here, but then there are always responding to emails when they're on vacation. And we're setting the example that we don't really love vacations here.

Um, so the other thing that I think an organization can take as like a really easy step is just declaring one day, the day where we don't do meetings, we limit meetings. Now of course, stuff happens. Um, and certain functions like support are always going to have maybe conversations that are occurring inside that might require them to hop on a quick customer call.

But these are work related things that actually move the mission forward. So one of the things that we wanna wanna really focus on is whether or not we can create those really focused days. Um, if you're interested in kind of pulling this into your organization, there's tons of, uh, like AR articles out there about creating a no meeting day.

And then I think the other beautiful thing is if you have somebody in your organization who looks at mihi sheets, MI high's, work on flow state, um, because that's really what we're trying to create here is a day where people get to focus, um, where they get to research, uh, where they get to look into problems and challenges. I think the other things that are still kind of part and parcel of eng life right now, right, are also creating hackathon space as well too, right? Space for innovation space to think.

Um, and then I'm also a big proponent of putting Slack naturally into any sort of plan or any sort of understanding of our organizational velocity that we have. Like no one should be planning to a hundred percent of what they know they can do. Um, it's always better.

I have never worked at an organization or worked with a company when I was doing consulting where if we under committ and then Overdelivered, someone was upset. But I've worked in plenty of places where if we overcommitted and underdelivered people got upset. So I think, you know, to yourself a favor plan to at least 80%, maybe less if you're doing interesting or new things or you have new people coming into your organization.

But Mike, to your point, that's where some of the tools can come in handy because they can tell us data around when we have a new person join, maybe an established team. Our team velocity is expected to go down. And this is just facts.

We have to train, we have to help, we have to assist. Um, if we have new work that's coming in that's new for the team, those are the sorts of things where we have to assume that our velocity would decrease. And so it's just, I think taking a humanistic view.

Um, and these are the things too that I hope that, uh, you know, intelligence inside of our organizations via, you know, bots, AI agents, agent networks, will help really surface. It's one of the areas that we're looking at, at tempo is just kind of looking at the overarching plan and how those things change based off of how the effort is changing on our individual teams. All right, Shannon, thanks for the insights, but I want to clarify one point real quick.

Um, no meaning days. Is that like once a week or every other year? How often?

Once a week, Mike, if you could believe it, and I think the, uh, the gains from that would, would definitely pay for themselves. So, uh, definitely worth the worth. The, uh, time worth, the effort, worth the investment.

And, uh, a quick, easy step that I recommend folks take. All right, folks, you heard it here. One thing to think about maybe is find that list of 10 things that annoys you and find a way to automate it, and life will be a lot better.

Shannon, thanks for being on the show. Thanks, Mike. Have a good one.

All right. And back to you guys in the studio.