Nickolas Means on Software Engineering, Data Liability, and Good Coffee

Welcome back, esteemed listener, to another episode of data driven. In today's episode, we have the pleasure of delving into the mind of Nicholas Means, the vice president of software development at SIM. With a keen intellect and a propensity for weaving together multifaceted concepts, Nick touches upon the enthralling topic of shame and its relevance in our ever evolving software

industry. Prepare yourself for we shall ponder the intricate connection between shame, vulnerability, and the cultural shifts within the software engineering landscape. As we explore the depths of these subjects, Nick leaves us curious and yearning for more recommending a podcast episode that unravels the intricacies of this enthralling topic. Now on with the show.

Hello, and welcome to Data Driven, the podcast where we or the emerging fields of data science, artificial intelligence, data engineering, and occasionally, ever so occasionally, IT operations and engineering. Today we welcome Nicholas Means to the show. Nick is the VP of engineering at STEM, Spelled s y m, not like the video game kids, and it's an adaptive process tool built for

developers. He's been an engineering leader for more than a decade, focused on helping teens build velocity through trust and autonomy. He's also regular speakers at conferences around the world, teaching more effective software development practices through stories of real world engineering triumphs And failures. Welcome to the show, Nick. Thanks so much for having me on, Frank. Excited to be here. Yeah. Awesome.

You know, and And we were kinda talking in the virtual green room is that you're not really in the data space, but you are, I would say, dare I say, distinguished software engineer, and There's a bunch of us in the data space now that kinda started in this world, and and I think one of the things that that, when your name came across my desk, I was like, reading some papers lately about, you know, technical debt in data systems.

Right? Mhmm. And I think that's kind of the big dirty secret, and I think that there's a lot that we can learn from software engineering practices, in this space as well. Yeah. For sure. So what when you say autonomy, you know, as an AI geek now, when I think autonomy, I think Something completely different. Well, I'm I'm assuming you mean people being autonomous from kinda that Dilbert type corner, you know, pointy haired boss guy. Right? Yeah. Absolutely. So you had a a pretty distinguishing

distinguished career. You probably have had worked for people like that, and probably inspired you to kind of go in the other direction. Is that is that true? That's part of it for sure. Yeah. I mean, I, You know, I I think my my journey into engineering leadership kind of involved being in, like, some locker room kind of cultures where the loudest voice won.

And and a lot of my motivation from shifting from writing code to being on the other side of the business, being being a manager, Was wondering if I could do better, wondering if I could could build teams that functioned more humanely and actually empowered each other and and supported each other in getting their work done. And the the last 10 years of my career has kind of been a journey in that direction. So what was that moment where you were like, I could do better?

Interestingly, it was an episode of the Ruby Rogues podcast several several years ago, that that featured Alex Harms, talking some about the work of Brene Brown, and shame and vulnerability in the way that those concepts can inform the way that agile teams communicate. And that was, like, when my eyes really kinda opened to the idea that maybe the the thing that I was living through wasn't the only way to do this and that that it didn't have to be this hard. Interesting.

What does that mean shame in terms of, I mean, you you mentioned kind of the the loudest voice in the room wins, the locker room mentality, kind of like, you know, you know, it's like we're we're chimps back

in the savannah, Back mill 1000000 of years ago. Right? Like, we like like, is that is that obviously, obviously, at some point in history of The human species that might have worked, but I don't think in software where 90% of it involves kind of the prefrontal cortex, I think e I don't think that's gonna work, and What what was it about the Bray Brene Brown kinda concept of shame and vulnerability that kinda, like, made you Connect the dots because Brene Brown exists in

kind of a different world than than your average, you know, software. I'd like to know more about that podcast episode. We'll have to link the to that episode That sounds interesting. Yeah. I mean, so for me, it

so so part of it is that loudest voice always wins, but one of the effects that That almost always happens when you have one of those really loud voices in the room is that it tends to silence other voices. It tends to make People afraid to raise their hands, say I don't know, ask

things that feel like obvious questions to them. And all that's kinda rooted in in shame And not wanting to be vulnerable and and not knowing something or or feeling shame that you don't know something that you think should be

obvious to you. In reality, it's not. In reality, one of the things that that distinguishes the best senior individual contributors is willingness to say, I don't know, willingness to ask Questions when something comes up in in a discussion that they don't know about, but it takes a long time in your career to kinda build yourself up to that

point of confidence. We're saying I don't know is an easy thing for you to do, unless you're in an environment that's that has high psychological safety and where those questions are invited And and where the the environment is very much set up to be oriented around growth and around making sure that everybody is able to ask Those questions able to push back on each other when they don't necessarily agree with the the direction something's taking.

Not in a allowed chest thumping kind of way, but more in a, Let's talk about this. I I don't know that that's the best way to proceed, but maybe there's something about your position that I'm missing and just that that sort of curiosity. Interesting. How does the how does shame relate to imposter syndrome?

Interestingly enough, my very first conference that I ever did was on impostor syndrome, and that this was kinda this line of thinking is kinda what sent me down that road and made me realize that was a thing that I was dealing with. It's it it very much relates to it. Very much the idea that it it's hard as a software engineer to kinda get perspective on how Good or bad, you are as a software engineer. You're

really dependent on other people's feedback to do that. And that's one of the key components of impostor syndrome is anytime you're in a career Where something is subjectively judged, which code quality subjectively judged. There's there's rules. There's best practices. We don't agree on the rules and best practices, So that puts us squarely in in the subjective side of the house. So it's really no different than than being a professional musician or a ballerina or something like that.

You're being judged by the the quality of your work output, but it's a subjective set of standards. And people in fields that are judged by subjective standards are especially prone to impostor syndrome. Really? I did not know that because, I I mean, it may make sense as you explain it that way, because if you're a civil engineer. Right? The bridge is either gonna stand up or it's not. Right? It's gonna shake too much or it's not. Right? The wind, like, the Tacoma Narrows Bridge, right, the

wind's gonna hit the wrong way, Something's bad is gonna happen, or it doesn't. It's it's it's a very real world thing. I I I've often kind of wondered as software engineers, or even this applies to data people too. Right? What we deal with is so abstract. Mhmm. You know, that it is hard to kind of gauge that, and and I I can't be the only one that thinks that Because it's subjective, organizational politics plays a huge role in how someone's judged. I'll share a story. I used to work at this

consulting firm. Actually, it's back when I met Andy, who's not here today. But, This guy wrote the most awful code. I don't wanna say his name for, you know, lawsuit reasons, but his last name and the word code became a synonym for garbage code. Right. But he was such a politician. He would walk around, and, like, everyone loved this guy. No one wanted to call him out on it even though he Wrote the most god

awful bits of code. Yeah. And and that was when you know, I I wouldn't say it was an moment, but I was like I was like, oh, he should be selling used cars. He should be kept away from a keyboard. You know what I mean? Yeah. Yeah. Yeah. I mean, that gets into, like, the Dunning Kruger effect, right, where Where the people the people that often feel the worst at their job feel that way because they know what bits of knowledge they're missing, and the people that feel the best at their job feel

that way because they have no idea what knowledge they're missing. They they just feel very confident in the things that they do know, and they're not worried about the rest of it. So it's sort of this idea that the more intelligent you are the more you're gonna struggle with this stuff. Interesting. It's almost like, the self reflection kind of Guess in the same recursive into infinite loop and you kind of lose sight of it. Yeah. And if you and if you do, if you are completely oblivious,

You're unaware. It's it's kind of like a a a cruel trick the mind plays. Yeah. Absolutely. Interesting. So

How did you we were talking about physical engine, engineering and things like that, like, what obviously, you know, a bridge falling down that happens. Right? What what can we learn because it's subjective, it probably I don't I never say never as a policy, usually. See I even qualify that. What can we learn from real I hate this this was always a thing because there's always, like, there's real engineers. Right? Like, the people who build stuff and but I mean,

like, what can we learn from physical, engineering disciplines? Right? Because this this has come up before, I I can imagine, and What what can we learn from them? So the

fascinating thing about that is the the lessons that there are to learn in physical engineering disasters are all still based in the human side of it Because even though steel is steel is steel, and it behaves according to a set of physical rules that we know, the people that work with steel still make mistakes in how that steel is gonna behave. I've done, you know, I've done a series of talks kind of on on connecting real

world engineering disasters to the software world. One of them that the the steel metaphor brings to mind is the one I did on City Corp Center in New York, which is the building that's sort of built on stilts. It's It's built up on 4 legs. The legs are actually on the the sides of the building, not in the corners, and that created some wind

loads that weren't accounted for in the original design. And then when it was actually being erected, they changed the way that they fastened the structural members together, thinking that the the original designer structure had overprovisioned them, and that they didn't need that amount of string. They could just do rivets and stuff, or they could do bolts instead of rivets. And it turned out that it would've it was vulnerable to a 100 year storm, and

a 100 year storm could have actually blown that building over. And so it's the the story kinda gets into Fill the Measure, the the engineer that designed it, Basically raising his hand and going, hey, I figured this thing out. Thanks to a comment from an engineering student. We have to fix this building and, like like, sort of the process of talking about what happened himself, talking about the mistakes he had made in the design,

bringing it to the attention of people that could then do something about it. In this case, the people that own the building, Citicorp, who financed the work, who worked with insurance companies. The whole thing is a story of, When you make a mistake, it's better to raise your hand early than try to sweep it under the rug and try to cover it up, because you'll end up making a bigger mess in in the process, and the consequences usually aren't what you've built them up to be in your head.

So that's that's sort of an example that that kinda gets into the human side. No. That's awesome. Like, there are there are things in my life that I if I had learned that lesson sooner, would have been a lot easier. I I think that's true for all of us, and that's one of the reasons that I I find I mean, I'm I honestly, I kinda came into this line of of conference speaking because I like to read about disasters a lot. I I watch way too much Seconds from Disaster as a kid, and I've

always been infatuated with this stuff. And it's it's sort of a way for me to Justify taking a really deep dive and learning a lot about one of these things and getting something productive out at the other end of it versus it just being a long Wikipedia Safari for its own sake.

But I but I you know, there's I think there's a lot that we can learn from people that have been doing engineering longer than us because the the human factors The the communication between people working is still a a thing that existed in the physical engineering world, and that's been going on far longer than we've been building software for computers. So there's absolutely things

that we can learn from those disciplines. Interesting. And in regards to the Citibank building thing, I remember seeing something in the History Channel about those. Apparently, like, overnight, like, they had crews working in the middle of the night. And then is it true? I don't remember all the details, but is it true they largely kept a hush-hush? Mhmm.

Yeah. They did. They would go in, and and they would build these welding shacks around the the places where they needed to weld inside the building because all of the all the cross members were exposed inside the building, and it just been drywalled around them. So they would go in and build a little plywood shack, and knock the drywall off, and and weld it. And there's pictures of the building where you can see it lit up in the night with somebody welding on one of these

structural members. Wow. They didn't tell people what was what was going on. It came very close to needing to order an evacuation because of a tropical storm that was headed towards New York, and the storm ended up turning away at Last minute. Wow. Wow. I do remember the part about that 100 year storm was, basically, almost happened. Yeah. Alright. Here's Andy. And in all of our years of podcasting, it's the first time he has, shown up late, so, kudos for him.

I will I will I will either leave this edit raw, or, Or, kind of include it, with the, the thing. So I'll I'll I'll clue Andy in. Nick Means is the VP of software develop

this I will edit out. VP of software development at a place called SIM, and he has connected, he's done a lot of personal research out of his interest in, disasters, and how those lessons can be learned, in software engineering, where software engineering, he can I can I can tell if I'm paying attention, is that, you know, it's largely been this, you know, who

who can Pump their chest, the loudest type thing? And it's not really been the there's a certain pecking order that May have worked in ancient times, but works terrible in software engineering. Is that about right? Yep. Cool. Oh, wow. Okay. I'm gonna have to listen to the first part of this. This reminds me of Spaceballs. This, like, Spaceballs. Let's go to the instant machine own video. When will then be now? Now. Just now. What is this? This is now. Well, what happened? Classic.

Never play that part again. Alright. So now that we were on I'm sorry. What? I was gonna say it's nice to meet you, Nick. And, You as well. Yeah. Yeah. Sorry Sorry, I was late. I've it's a great problem as a consultant to have being double booked and stuff, and usually, we're able to work this out, but, I am experiencing too much business. Again, great problem to have. Still a problem. Yeah. Great problem. Especially right now, it's a great problem. Right? Yeah. Yeah.

So I'm very, very thankful and grateful for that. But, I know Frank Frank did a wonderful job, and I'll just, I'll hush now, and, we can get on with the show. Alright. So we were talking, so so that's interesting. So With software engineering, with with buildings and physical things. Right? You know, the nuclear reactor can melt down. Right? The, The, bridge can collapse, the Citibank building could almost tip over. With software engineering, you got a lot of other problems too. Right? I mean,

Security breaches Mhmm. Come to mind. And and in your in your, kinda, your your sheet, like, You mentioned something called a blameless mindset. What what is a blameless mindset?

So, I mean, it's really the the orientation that anytime something happens, your primary goal should be to learn from that thing, not to figure out whose fault it is. It kinda gets into, if if you if you've done any research into, like, safety 2 or or human factors. It gets into the work of Sydney Decker and and what he calls forward accountability. Kind kind of the idea is that nobody comes to work intending to do a

bad job. And if if they make a mistake that causes an outage or causes a security breach, They probably already feel pretty bad about it and don't really need you piling on most of the time to learn their lesson. What they do need is a chance to tell their story, so that they can kind of put the facts together in their own mind. They can help other people learn from from what they just did. And that that kinda gets into when

when something happens. It's often very tempting, especially for for us pointy head pointy head boss types To point the finger and and to find somebody on whose head the the blame for this thing lays. But when you do that, when you focus on establishing blame as as a primary Goal in one of these situations, you prevent people from learning, and you prevent people from raising their hand when it happens. You encourage people to sweep it under the rug. Kinda what we're talking about.

It's it's the thing if Phil Meacher had done this with Citicorp Center. Citicorp Center probably would have fallen over at some point. And so having a blameless mindset when something goes wrong encourages people to raise their hand sooner, bring other people in on the solution, Let the whole organization learn from the the mistake that they just made. And and, you know, it's kinda

rooted in a systems thinking mindset as well. You know, how can we Change the system so that a a mistake that's shaped like this is more difficult to make in the future. So here's a random question. I noticed that GitHub has something called the blame tool. I think it's part of Git. Mhmm. Is that is that a tongue in cheek reference, or is that actually, Like, actually a blame. Like, what are your thought? Well, I don't know the history of that,

so maybe maybe you could tell me. And then Yeah. I mean, it it is from Git Self not from GitHub. It's something that just showed up in the in the GitHub UI from from Git. I actually, on my own system, alias it to get credit, so I don't have to type git blame. Oh, I like that. Oh, that's awesome. And that's

I I it's definitely not my original idea. I know a lot of people that do that as well, just because Get blame puts you in sort of a certain frame of mind when you're reading code, and it's often not a helpful or charitable frame of mind. Whereas get credit is more like, okay. Who can I ask to hear this story of of why this line code came to be? Yeah. That was because that

yeah. When you mentioned blameless mindset, and I was like but, I mean, I guess that speaks to kinda, like, you know, like, you know, the origin story of Git, I guess, Blame the blame tool or I don't I don't know. Like, it just to me, it just seemed like there's gotta be more to that story. Yeah. And when I first heard the tool, The guy I was working with, he thought it was funny. Oh, they have a blame tool, so you can always know who's to blame. And I was like I was like, that's kinda

mean, actually, you know. A little bit. A little bit. I mean and again, you know, it gets into, like, the the prime directive of retrospectives if you've done spent any time in the Agile world. This idea that everybody was doing the best that they could at the time that they did it and made the best decision they could with the information they had. Right. What's interesting in as you see those That agile processes kind of happen, right? There's there's

the theory, and then there's the practice. Mhmm. And Its organizational culture tends to take all the oxygen out of that room. Yeah. You know and and you're not surprised so I guess that's that's a thing You know? I

I I like to and I forget who coined this distinction. It may have been kept back, the idea of big a agile versus little a agile. Yes. Big Agile, the idea that there's all all these off the shelf methodologies that you can just pick up off the shelf and adopt in your organization, and and suddenly the the heavens will part and will sound and you will be more agile. You look at something like SAFe, the

scaled agile framework, and you can pretty clearly see that that's not the case. It's just Waterfall in disguise at the organizational level. Whereas more more little a agile is the actual principles, the spirit of Of sort of the agile software movement where it is more autonomous. It is more short planning cycles, getting feedback early, shipping in small increments, that sort of thing. And it's really easy to pick up an off the shelf agile methodology and not do any of that stuff.

Right. I I remember hearing an interview once, a podcast, probably a decade ago where, someone referred to their, their software development life cycle as Scrum Bud. Mhmm. And so when we're doing scrum, but and then, you know, something followed that wasn't scrum. And it sounds a lot like what you're describing. Yep. Absolutely. Yeah. One of the reasons I I tend to be more with my teams,

more Kanban inspired than Scrum inspired. And and the reason for that is Because I've seen too many teams try to win the sprint, and and it sort of creates this perverse incentive to just get code across the line no matter what it takes. Yeah. I I like the community aspect of Kanban, the swarming, and Mhmm. You know, I've seen that work. I I actually learned that on a real live plant floor. So, you know, I've got I I used to joke with Frank that I've got about 8 more years of books I can write,

process engineering because I know where they're going. Yeah. And, you know, and and what's interesting is we've reached that phase where I was in manufacturing in the late, nineties, And we reached that phase where we learned where it wouldn't work. Mhmm. For instance, it didn't work in engineering.

So it's interesting that we're kinda getting to that maturity. I guess that maturity would be a good description of it, where we're seeing in the context, Especially if software engineering that is falling over some. Mhmm. It works really, really well on the plant floor Mhmm. When you're in a manufacturing environment, that quality goes through the roof.

Deming's methodologies are phenomenal. The, And maybe you've already covered this, but the culture wherein a lot of that, you know, from the manufacturing perspective was developed, is a vastly different culture than we have today in the United States. It wasn't even I mean, it was Japan. Right. You know? Coming out of post World War 2, and That's that is a different place. Mhmm. It's probably different than Japan today. I'm

sure it is. Yeah. You know? So That that has a lot to do with it, and you did, I heard I heard the screed behind the words about corporate culture. That's that's a huge driver. Mhmm. It it just is. Alright. I'll show up. It's and it's, you know, it's it's not it's really not any different than than what we're talking about about off shelf agile methodologies. Right? Like, all of these things are tool are toolboxes.

There's useful things in all of them, and there's things that don't apply and don't work On an organization by organization, team by team basis. Absolutely. And the trick is you have to be able to have all of these tools in your toolbox and then go up to a team and go, oh, I know this shape problem, and I these are the things that we can try that that will help make this better. Right. Right. What's your, sorry, Anya cut your head. Go ahead. Go

ahead. How do how does, how does a software engineering team Change or leadership within software engineering change the the the organizational culture, Because I think that's a big problem. I think that software is eating the world. I think that was a Mark Zuckerberg quote, and I think that, yeah, Definitely since ChatGPT, I would say AI is eating the world. Right? But but ultimately, I'm old enough to remember when software people were those weird people that they they stuffed us in the

basement Mhmm. And did not wanna hear anything from us Other than everything's working fine, everything's fine, they certainly did not wanna hear, management philosophy of, stump speeches from us. I imagine that's changed a little, but how does how does someone who's listening to this Wants to affect chains, wants to kinda bring that blameless mindset into their organization. How do they start? I know that's probably, like, a 3 hour talk, but Where would they how

would they what's the first step? Yeah. I mean, what what a great question. You know, I think step 1 is just learning and and kind of figuring out where this information exists. So, like, reading some of the blog posts from John Alsbaugh when he was When he was CTO at Etsy, reading some of the work of Sydney Decker, that he's done on safety 2. I mean, John John Osborn is still out on the speaking circuit doing talks a regular basis.

So there's there's plenty of material to learn from out there. I think it's it's probably most at home in the SRE community right now. That's that's where I see a lot of safety cultures and human factors research coming out as in NSRE at the moment. It was it's still in the dev ops

movement as well. That's kinda where I got acquainted with it. So step 1's kind of learning and then just teaching, giving people the opportunity to realize that There is a different way that some of the stuff can be done. You know, as far as an engineering leader being able to affect larger change in an in an organization, The one advantage that an engineering leader has is that software engineering salaries are usually one of an organization's biggest cost centers.

And so it's pretty easy to make a case that optimizations there will pay off if you can make a A persuasive case for the optimizations that you wanna make. And that's where some of the things like getting into manufacturing theory and queuing theory and systems thinking and being able to put together a very data driven kind of case around some of the improvements that you're trying to affect and the

ways that you're trying to affect them. It it's funny. One of one of the most common interventions that I found myself making over and over

again with engineering teams is putting WIP limits in place. Just because when an engineering team is trying to work on too many things at the same time, they end up spending so much of their time on context shifting And and trying to load up new contexts and pick up a project that's completely different than the one that they're currently working on so they can

provide effective code review, that sort of thing. And it's pretty easy to kinda talk through the data of if we work on less, we can get more done, but it's really counterintuitive on the surface when you first hear that statement. Well, the whole drive towards parallelism. Mhmm. You know, from a machine level right through you know, it bleeds through. They're all leaky abstractions to throw out some other Yep. Terms. But, you know, that that whole idea that if you

do things in parallel, you're gonna be able to accomplish more. And I've seen, I'm gonna I can't remember the book. I was reading reading a book by someone. It was maybe 2, 3, 4 years old, and He was talking about just the exact opposite, and he had use cases and it just you know, serialize it, and you'll get more done. And it it it's exactly that context You eliminate that. Human brains stink at constant context switching. Awful at it. Yeah. Yeah. So Great. Great point. Interesting.

So another thing that you you kinda Mention is talking about compliance. Mhmm. And before everyone kind of tunes off, turns off the the thing and stops, stops listening. Bear with me. There's a point here, and I think it's important. No one gets excited about compliance. I I know I know that. My wife works in IT security compliance. No one's happy to see her. I'm I'm happy to see her, but no one at her job is happy to see her. Dear Roberta, you'll never

Alexa, order some flowers. The, but With the rise of software being more and more important, more critical to our, I was talking to somebody else. It might have been in a preview, The another guest on another completely random topic. I think regulation is coming to the software industry whether we like it or not, Because of its core kind

of nature to our, just economy and infrastructure. Mhmm. And I think that compliance is gonna be one of those things where, You know, learn it or, you know, learn it, love it, or, you know, leave the industry. Yeah. Yeah. And and, Yeah. I'm sorry. So so, like, how do you how does that it seems like that would kinda dovetail into this. Right? The the the Learning from

mistakes and and meeting these compliance. I mean, certainly, we see it in data and various data compliance schemes, but but how does he think this is How does this gonna affect kind of software? Yeah. I mean, the the first thing

I was gonna say is you can you can already see some of this in things like GDPR and the California privacy regulations, The the stuff the White House has been doing lately on software bill of materials, we're starting to see it kind of creep in in in the in the periphery of the things that we work on. You know, it's it's tempting to just look at it and go, this is dumb. This will never

work. It's not gonna make any difference. But there's a there's a There's a more terrible way to look at it in that it's pointing at a thing that actually is really important. You know, to to your point, s soft reads the world as organizations hold on to more and more and more and more data. That data's a liability, and If if we're not taking steps to make sure that, a, we're only holding the data we actually need to hold, and, b, we're doing it as

carefully as we can. We're putting as many walls around it as we can, and still be able to do our job on on an ongoing basis. You sort of have to put that responsibility hat on and and think about it in terms of how can I be a good steward of the data that people have entrusted to me in in this organization that our customers have given us? Yeah. And and in that that perspective, when you're looking at it

from the Spirit of law versus the letter of the law. It makes some of the controls that you need to put in place for some of these compliance regimes a little bit easier to swallow, And it also gets you into sort of a an outcome mindset because, you know, it's really easy to go through and and comply with some of these regulations with checkboxes. Just do the things they say and and not really actually make any difference in the overall security of your organization.

But if you look at it from a perspective, this is actually a And and we should actually be doing this, then you can go about it and put meaningful controls in place that that don't make it harder to get work done. They just make it safer to get work And that's ultimately that's ultimately the goal. That's I mean, that's what we're working on at Sym. It's sort of the whole point of the product. Yeah. It's a good segue. So what is Sym? SYM. Not the

Sims. I'm sure that's not I know that's not the first time you heard the joke today, but, You know? So It's it is not the 1st time I've heard that joke for sure. What what is what is Sym do? Like, what What is the the product? It it's essentially at its core workflow engine. It allows you to build simple workflows to request and Orchestrate access to to production systems. It's probably easiest to explain by just telling you

how we use the product at SEM. We have all of our production infrastructure behind our own product. So when one of our engineers needs access to a production system, they just they create a request in Slack, and then anybody else on the engineering team can approve that request. So kind of a a 2 keys to launch the rocket approach. And then in the back end,

there's some code that runs in AWS. We assume a role An AWS that lets us escalate somebody into that administrator access role or whatever permission set that they've requested so they can go in and do their job. And then an hour later or or 4 hours later, whatever time interval they've requested, that access expires. So you don't end up over time accumulating that janitor's key ring of System access that you don't actually need on a daily basis. Right. That's cool. That is interesting.

Now and it it you said something, a a a little bit ago that I thought was might have sound blasphemous to some of our listeners. Right? The data is a liability. Yeah. But the more, like, you kinda unpack it, oh, yeah, I mean, you're right. Like, you know, we're so conditioned to think of data as an asset, and and asset only. Right? That I think we will lose sight of reality. Right? Or the risks of holding data. Right? And I was just thinking, like, you know, if I

had a company, and I had, let's just say, some kind of PII. Mhmm. Right? And I, after so many months, or once I'm done doing what I'm doing, I purge it. Right? I probably would sleep better at night if if I heard, about, like, there's a there's a breach or anything like that. Right? Like, it's kind of like, I think I think that there's a, for lack of better term, data

hoarding happening in a lot of organizations. Yeah. And I understand it, right, because there's this If we've been so conditioned to think data is only an asset, right? Oh, well, why not just store it? Store it is cheap, you know? Right? But if you also think that it can also be a liability, and obviously not all data types are created equal. Right. Yeah. Of course. And not

all liabilities are created equal. Mhmm. Then that becomes a pretty cold calculation of, well, yeah, maybe we'll figure out, you know, if they have an even or odd social security number. If that means that they're more likely to buy our product. Yeah. But I don't wanna even hold that stuff anymore. Right? Or I'll collapse it into, you know, Flag 1, flag 2 based on that. Right? So, you you know, I I I like that. I hadn't

really thought about that. Yeah. I mean, one of the interesting use cases, you know, if you think of health care data, there's some of that that you have to hold. Right. But HIPAA is pretty strict about who can access it and when they can access it. So one of the workflows that we've seen set up is is requesting approval to access a particular patient's data with a reason for needing that access So that it's all audit logged.

It's all recorded, who requested it, who approved it, that there was an actual business need to access that data, that it wasn't done willy nilly, or that that you had the patient's permission to access that data. You know, just creating that that simple little bit of diligence to say, yeah, this data access happened for a reason.

Right. And that it's automatically documented, so then you don't have Some tedious manual process where you have to fill out a form and and fax it to headquarters and wait on them to contact somebody and, you know, the the typical Byzantine Data access processes in health care. Very cool. I I tweeted that. I didn't overheard. Oh, I heard that more and more lately here, because during the pod you know, the podcast recordings because, definitely trying to tease season 7. And, yeah. It's

that's a that is a great a great line. It's it's got controversy written all over it, Nicholas. Thank you. Absolutely. God, I can have one. I totally agree with you, on on that. And it's you know, I and I understand the drive to say data is an asset Because for so long, people just looked at at data as being something kinda neutral. You know? It was hanging around. Maybe they were, Yeah. I was taking up space, filling up the sand Or byproduct. Or

byproduct. Right? Right. You know, I I always think of the story about I I don't know exactly the chemical Or whatever, but apparently, I guess steel mills used to produce, like, this kind of ash, and it was useless until somebody figured out that it's Good for, getting traction in snow or for car for for parking lots or something like that. I I It's it's a bit late in the day. It's been a long day, so I I don't forget exactly what it's about, but

I remember. So, you know, so the story goes is that, you know, whoever figured that out, I mean, they the the steel companies just, like, here, if you're willing to take our trash, go ahead. As soon as they found out that this guy was making money off that, Suddenly, it was no longer free. They charged, like, you know,

$5 a ton or something like that. It was just interesting how How, you know, as the thing goes, 1 man's trash is another man's treasure, but as soon as it becomes a treasure, then other people are gonna see that. Yeah. I mean, at point in time example, Reddit's in the process of making their API paid right now so that you have to pay to train, like, large language models on it. Interesting. I would shudder to think what a a large language model training that would

be. Little scary. You know, I don't wanna go to go down that That's something I've been watching a lot lately, for some for some playtime work I've been doing. And, it dramatically dropped, The, the cost to train because the large language models aren't as large any Mhmm. At least the sets of tokens and such. Yeah. So it's gone down to, like, less than $100. That that's on certainly less than 1,000, but in some cases, like, you know, 30, $40 to train him

on. Yes. Which is a far cry from the 7 to 12,000,000 that Right. Yeah. That some of the more popular ones have been on. So it's, you know, and and and it it amuses me that, you know, you have countries that are trying to ban chat gpt. Right? The the the cat's out of the bag, genie's out, whatever, Genius on the bottle, like, you can't stop the signal, you know, like, it's already out. And Great reference, Frank. Yeah. I was talking to somebody yesterday on a completely on nontechnology

related thing, and I said, you can't stop the signal. And he got the reference, so which I thought was pretty funny. But I'm sorry I cut you off, Nick. No. Oh, thought I did. No. This is a fascinating conversation. I think we can go on for hours, but we wanna be respectful of your time and switch to our pre canned questions. I will kick off number 1 because we have to change it slightly. How did

you find your way into technology? Did tech find you, or did that Techlife, Where you found that Tech Life?

So I had an uncle that when I was, gosh, 9 or 10, Had an old Amiga computer, and that was the 1st computer I spent any significant time with, and just sort of Really kinda fell in love with it as a toy first. And then, you know, not long after that, IBM PC's PC DOS came out. Basic was everywhere. Went to a summer camp and learned how to program in basic. And, the the first productive thing I ever did on a computer was I wrote a 20 question quiz in Apple 2 Basic over Egyptian history for a

6th grade project. And I Nice. We didn't have a computer at home at the time, so I stayed after school working on that Apple 2 to write that code. And just I I obviously got a good grade on the assignment and just have I've been infatuated with being able to make the the magic blinking box kinda do what I want it to do ever since. I like that description. Very cool. Our second question is, what's your favorite part of your current gig?

My favorite part of my current gig is kinda it gets into what we were talking about at The the top of the call, sort of being able to really shape and and build a culture where the the people on the engineering team are really able to thrive, and really able to support each

other. It's a really fun group of people to get to work with, and and the way that they're able to support each other in projects and in in growth and, learning new things is really, really fulfilling for me from from a leadership perspective. Interesting. So we have 3 complete the sentence, questions. When I'm not working, I enjoy blank. Trying to come up with 1 answer,

but this is really hard. I'm a huge soccer fan, so I'll say that. I we have season tickets to Austin FC, watch a lot of EPL with my son. My son plays. So Oh, cool. A a lot of a lot of 90 minute increments of my life are spent watching soccer matches. Awesome. Our second is, I think the coolest thing in technology today is Blank. That it's

becoming more humane. Like, the the conversation that we had at the top of the call is one that is Far more common today than it was 20 years ago when I started my career. And I think it's only gonna get more that way, because As systems get more complicated, we're gonna have more sophisticated and complicated discussions about humans' roles and interacting with those systems. AI is a great example. What part of jobs does this supplant? What part of jobs does

it augment? How do we do it in a safe way? How do we keep it aligned with people? And at at at the root, Those are all questions about how do humans interact with technology and with each other when technology's in the room, and I think that's a really interesting bit of history to get to live through. Interesting. Our 3rd and final complete the sentence. I look forward to the day when I can use technology to blank. I just did my taxes, so autonomously do my taxes. That would be nice.

Here's a moonshot goal. Have, some kind of large language model that can explain the tax code in the United States. K. Good good luck with that one. It would just Yeah. Yeah. Answers. Oh, I thought of, like, 3 things to say, and I'm not gonna say either of those things Because We wanna keep our Itunes clean rating. I'm not gonna I'm not gonna finish that segment. Yeah. Good segue to that. Share something different about yourself. And do remember that we're a family show,

and we wanna keep that clean rating. Something different about myself. I am really, really obsessively into To pour over coffee. I spend an awful lot of time and energy trying to dial in my daily cup because it's it's that just Even the ritual of making coffee in the morning is sort of the thing that mentally transitions me into work as someone who works from home. Uh-huh. And, it it's one of those things that The more time I spend on it, the more I learn about it, the more it rewards me with

a better cup of coffee. So you're doing the filter In the kind of the ring, and you put the grounds in Mhmm. And then pour the coffee through them. Yep. That's interesting. So, yeah, I've I do a French press, but I've been doing that for I don't know. It's way too long. But the, the I've heard AeroPress. I've never I've had a lot of people recommend AeroPress. I've never really tried it. It's great. So is it? It's a it's a really easy

way to get a really good cup of coffee. So what do you think the big difference is then between AeroPress and pour over? With AeroPress, Pressure is a component of how you're brewing. I mean, it's not anything close to espresso. Yeah. But but you're generally going to brew you're gonna grind a little bit Feiner for AeroPress, you're gonna extract a little bit different notes out of the coffee with a little bit of

pressure that you add. So you kinda have to dial in the rest of things to make sure you're extracting the part of the coffee that you wanna drink. You said notes. Mhmm. So is that how you think about it musically? Flavor notes. Flavor notes. So light. I didn't understand. Yeah. I mean, you know, if you get into, like, the the one of the easiest ones to taste in in lighter roast coffees is the difference between

a natural process and a washed processed coffee. So if you get a single origin washed processed coffee, you're gonna get all kinds of citrus notes from it. You're gonna get orange and lemon. If you get a natural process, it's probably gonna be weighted more towards the berry side of the flavor spectrum. So Interesting. A really good Ethiopian natural process coffee Prepared well is gonna taste like blueberry pie in a way that you just cannot miss. Wow. I've had really

I've had good coffee. I and I'm sitting here, like Like, when I when I wake up in the morning, like, I am the only thing I can functionally do is let the dogs outside and Lift the Keurig machine, drop the kappa in, hit the button, which I know is probably blasphemy, to to to to To the purest out there, but I'm just incapable of doing. However, if I am somewhere, and I can enjoy a good cup of coffee after I've had my first couple of, cops to get conscious?

I do I do I have had that that type of Ethiopian single source, and It's it's just very it's very strange. Like, almost has, like, blueberry ish pie thing going on. Like Like, what is in it? You know, like but and then I think it was at some airport somewhere. It might have been Seattle where they had, like they take coffee extremely seriously. And Mhmm. I was like, no. No. No. That's just part of the thing. I was like, oh, that's interesting. So,

yeah, you had me at Blueberry. Now I got you at Blueberry. Yeah. I'm a I'm a Blueberry fanatic. Nice. Awesome. Alright. So Audible is a sponsor of Data Driven. Do you do audiobooks and and do you recommend okay. Cool. So, any particular lessons you would recommend to our, listeners? I will give you 2. Right now, I'm listening to

John Scalzi's agent to the stars, narrated by Wil Wheaton, who is my absolute favorite audiobook narrator. I actually pick audiobooks based on the fact that he's the one that narrates them because he's just the the character he brings to the book, the way he brings out the story, I just I really enjoy. So that's a fun it's a really fun listen. And then on the nonfiction side, my favorite management book of

all time is Turn the Ship Around by, admiral David Marche. It's about a captain of a a nuclear submarine that sort of uses the same kind of things we've been talking about to to turn around the performance of The previously worst performing boat in the fleet. So kinda bucking military hierarchical management traditions for for something that gives the people on the boat more autonomy and ownership over over the thing that they're in charge of on on the boat into some pretty spectacular results.

Nice. And it's it's very narrative, so it doesn't read like a business book. It's a great audiobook listen. Yeah. Cool. Interesting. So, if you go to the data driven book.com, you will get 1 free audiobook on us, and then we get, Maybe enough to get a a nice cup of blueberry pie. One of those blueberry pack office. I was thinking the same thing if you sign up. If you sign up, health support to show helps us, kinda grow, and we're already

in season 7, but we're recording us before season 7 launch. So hello, future people. And then finally, the final question is, where can people learn more about you, Nick, and Sim? So for me, all I've got a lot of blog posts and all of my talks up at my personal website, nmeans.dev. And then for Sim, you can visit our website sym0ps.com. Sign up for a free tile trial, kick the tires. We'd love to get feedback on it. So if any of your listeners try it, have questions about it,

feel free to to reach out to me or anybody at Sym. We'd love to help you kinda get started on the platform. Excellent. Well, thank you very much. Any parting words, Andy? No. I'm just really sorry now after listening to the 2 answers that referred To the beginning of the show. I'm really sorry I missed that. I'm gonna have to wait. Well, we can use that that that machine from Spaceballs. You can go back And then redo it so future Andy will know how it all turned out.

Perfect. Perfect. I think Nick knows that we we, you know, we we do a lot we do at lee there always ends up being at least 1 movie reference, so we got that. Nice. Yeah. Alright. Thank you, Nick. Any last thoughts? No. Thanks so much for having me on. This has been a really fun conversation. Awesome. Thank you. We'll we'll let Bailey finish the show. And that wraps up another

intriguing episode of data driven. We hope you enjoyed our conversation with Nick Means, the VP of software development at Sym. From exploring the concepts of shame and vulnerability in the software industry Dri to diving into the fascinating world of engineering disasters. This episode has been a thought provoking journey. We delved into the importance of being good stewards of data and the significance of compliance with regulations, all while finding ways to balance security and

efficiency. As we wrap up, we encourage you to reflect on the valuable insights and takeaways shared in this episode. The path towards a blameless mindset, fostering stronger organizational culture, and embracing the principles of little agile are just some of the actionable steps we discussed. Remember, mistakes happen, but it's how we learn from them and share our experiences that truly makes a difference.

So let's continue to grow, adapt, and shape the software industry into a more resilient space.