Amir Bormand: [00:00:00] On this episode of the podcast I have with Meep, Paul Kazon, he is the Senior Director of Infrastructure Services at C CCC Intelligence Solutions. We’re gonna be talking about culture of accountability, empowerment, especially in the DevOps space. That’s where Paul’s background comes from. We’re gonna be talking about focus bottle.
Value streams changing culture and how do you measure that? I think Paul’s got a great background, had to talk about all this stuff. I’m excited to have him on. Paul, thank you for being on the show. Thank you
Paul Kocan: for having me. I look forward to it. Thank you.
Amir Bormand: Awesome. Let’s start off with two things before we dive in.
Tell everyone what your company does at a high level and then senior director of infrastructure services. What are some of the responsibilities you have there? Yes
Paul Kocan: My company CCC is. SaaS or a software as a solution company that serves the auto automotive insurance industry. So we have, two or three branches of the house.
You wanna think about it, the [00:01:00] connections, related to insurance companies with regard to automotive, damage. And then there’s the connections related to that to repair facilities. There, they, share estimates, et cetera. Insurance companies, et cetera. And then there is a line that has to do with the medical side of the house where people get it.
So we help insurance companies streamline and enhance their processes that to be obviously more efficient in, more empowered by which information. And, the goal of having claim is being processed without people touching it, and all sorts of. Opportunities for artificial intelligence around things such as taking pictures of a car, being car cri, the body of a car and having an estimate automatically generated just from the pictures, that type of thing.
So that’s what we do. And then as far as what does a senior director of infrastructure services do, and what my responsibilities are is I tend to send emails and go to meetings. No. I, I run I run, both [00:02:00] the delivery and the operations for your traditional, what you would consider network storage, compute, middleware, and, the kinda the internal guts of the things that make applications run.
Partnering a lot with both, on the operations side, making sure that our customers. Are delighted by the high availability of our, in, in, of our systems, as well as on the, a lot of the energy we spend is on the the software delivery side. As a software, as a service company.
We have a lot of different development teams and and a lot of different products. And we need to make sure that their features and, releases. Safely and efficiently and quickly drop their ideation through to production for customer use. And there’s also some complexity that goes on with that because like in any large enterprise any given team of products have connections and rely on other products, and there’s a matrix.[00:03:00]
Coupling between those products. And so there’s different ones and different complexities, and you need teams. Sometimes shared services teams, which I know people tend to, not to but to keep them all working together harmoniously. So I hope that.
Amir Bormand: You stay busy for sure. And I’m sure there’s a lot of what we’re gonna be talking about that you’ve seen and I’m excited to talk about it with you, is, know, talking about some, the culture of accountability and empowerment.
Obviously we’re of focused a little bit on infrastructure, your background, area. And I think you mentioned when we had spoken earlier, DevOps, blameless culture. And obviously things have to shift, things have to move to get to that point. But I think, I wanna start off, you mentioned something that was really interesting when it comes to infrastructure was the power of focus.
I’d love to maybe have you start off talking about what you meant by power focus and then we’ll dive in from there.
Paul Kocan: Yeah. And I think this was, the power of focus is what, if you would just summarize a lot of the practices out there that change culture.
So if you look at anything for the lean. Even use adopting OKRs or some aspects of, and some aspects of, scrummer know, just agile in [00:04:00] general. One of the things that it’s helped, it’s trying to help you do is give you a set of practices and behaviors that allow you to identify that which is most valuable, right?
So you take the if you take the agile principle of maximizing the work, not. That’s just another way of saying work on what’s important, right? So everybody who disagree with that, right? Yeah, of course you should work on what’s important. But especially when you get into a shared service where you have a lot of different groups who all think what their is most important to them is what’s most important to the company.
It can really cause a lot of, the term context switching, right? And the context switching. It’s expensive. It’s expensive for people mentally, and it’s expensive for your team. It causes a lot of waste. So what I’ve done when I’ve in my journey of being a good leader, which I’m not saying I am, but that’s just my goal.
And moving away of just being, moving away from, thinking about just systems. [00:05:00] Engineering around the, the bits and the bites and the code and the hardware and start thinking of technology companies and just products themselves as as they call it, right?
Socio techno technological services. That there’s a human element is that you want shared service to make sure there’s agreement across all the all of the stakeholders, all of partners, all the people who. Things from you. And I’m not gonna say customers cause I don’t believe in the, I don’t believe in the concept of internal customers.
I think that’s causes some of the problems. When people think of their partners as customers, they’re not, they’re partners, it’s like more like a marriage than as like a shop and it’s something bad marriage, so you gotta like negotiate and you gotta agree on what’s possible.
So what I tend to do right is, and these are principles, these are typical, you. Agile and DevOps and lean and, and theory of constraints principles is but people don’t do it. It’s surprising how people know it and you say it and they yeah. And then they don’t do it, is you really gotta make work visible.
You gotta make it known everything that [00:06:00] everybody’s working on. So that’s a, so when you talk about, culture and, I, everywhere I go, people wanna change the culture, but what do you mean by change the. Question. Like, What does that mean? What do you even mean? What’s wrong with the culture?
And then they say stuff like no one’s accountable and we just do, and they have these things. So basically it’s like everybody doesn’t do what I want them to do is what it means. It’s always everybody else’s problem to change the culture. But any person who works on any team can know what they’re working on.
Like you don’t need to ask permission to have a really good list of what you’re working. What’s a risk to that work? How, what’s distracting from that work? And if you know what you’re working on and what’s distracting from that work the kinda anti patterns to successful delivery you can have a really rich and meaningful conversation with your boss about, how he or she can help you move forward.
So if take that writ large and you go into a department need and you instill some practices, for example, you implemented agility tool like Jira, [00:07:00] something shared where everybody’s putting everything they’re working on and making, and you come up with a unified approach to Hey, let’s just agree on some terminology.
Let’s organize these things in the same way. And then you make some dashboards where you can put everything in a list. It’s surprising how many times in my life I’ve gone to companies and the, the CTO or whatever says I don’t know what they’re working. And I
Amir Bormand: guess that’s an interesting point, right?
You mentioned, setting up Jira, setting up the expectations. When we talk about accountability and empowerment, I think you mentioned a, a couple different things that we can pick apart is people have to feel safe to take the risk on of a decision, and then we have to allow them to be accountable.
So we want them to be empower. We want them to be accountable. But then there’s the subjective component is how bad was the outcome? Is it fireable? Like we want you to take ownership. We want you to go ahead and do what? Do what you need to do, but listen, if you get it wrong, depending on [00:08:00] the magnitude, we’re gonna fire you.
And that becomes difficult for somebody to raise their hand up and go, yeah, I’m gonna go ahead and make that tough call. People tend to go. I’m gonna think about the risk of me making that tough call and maybe I’ll punt or maybe I won’t, or I’ll suggest something alternative that’s more beneficial to me keeping my job.
Because, I don’t see a ton of companies out there, and I think this may be part of the challenge is, yeah, I don’t think employees really know what’s a fire. If I do poorly, I’m getting the feedback consistently. I understand. When I make a decision, if I’m empowered to make a decision, there’s a consequence.
And depending on how much risk and how much tolerance a company has, that is repercussions. And I think that’s be that’s a tough, it’s a gray area.
Paul Kocan: I don’t think it’s that gray. I think that I’ve lived through both sides of that. So when I first started in this, especially, in the infrastructure and operations space, accountability was king.
And there was this, what they would call taylorism attitude, that people were, are. They’re interchangeable parts and you gotta, you’ve gotta be [00:09:00] tough and crack the whip and yeah, you would, people would make mistakes and then they would there’d be repercussions that’d get written up that get moved.
They get their production access taken away, or they’d get fired, and there was this, whoa, and I think a little bit for good reasons in some cases, like there was a time and a place at companies back in the day. It was very routine for people to not follow the change control process.
That’s not for me. I’m, they would’ve this kinda ego that they didn’t have to follow the process because it was stupid and it took to, and they knew what they were doing. Okay if you are egregious about it and you’re gonna go and break process and you’re gonna sneak and do stuff, I, I don’t know if I want, I don’t think you’re trustworthy.
And, if you’re not trustworthy, then maybe you. Maybe you should be fired. But if you’re acting in good faith and you’re doing the best you can, which is what I believe, 99.9% of people who are technology are trying to do a good job. They’re not trying to be they’re not malicious.
They’re trying to be trustworthy. And you go and you [00:10:00] make a mistake and you do something. And the best thing that person can do and what makes. What I think is the best thing for the organization is for them to be very transparent about it and for, let me put it this way, when we think about failure, right?
Is this is all, not my own thoughts. It’s like Richard Cook and stuff, right? It’s that complex. Systems fail. That’s what they do, complex system. They fail, fails. Complex system’s always about to fail, and it’s only human action that keeps ’em from failing at any given.
All human action is a Campbell, right? So sometimes it, most of the time it works out, sometimes it doesn’t. So if you accept that and then you accept this, this is a profundity. I think this is something I’ve noticed my whole life and people used to not talk about it. Now people talk about it.
The big secret is that, in this organizations with complex IT systems and server, no one knows how it. We all know little pieces about works. We all know our part. There’s been so many times where something’s not working for a long time. It’s a really big deal and we have all the smartest people on the company on a call, and [00:11:00] no one knows what the problem is, and it takes a long time of them talking and experimenting and doing things again.
The long time, like the longest 25 minutes of your life. For the longest hour of your life of a, of customer taking problems, and you realize no one knows exactly how these things work. And this is every single company I’ve worked at. Now, this isn’t what you need to win everywhere worked at.
Then you go, then when you do a good postmortem, you’re like, okay, the company just involuntarily invested in a failure. And we need to get the return on investment by talking it through. And we need to be transparent and safe and people need to be able to and document it, and we need to get that, all that learning we had from the, like, how does this thing work?
Why did that break? That’s you gotta to have that mindset when you run, when you’re a leadership and you run it. And you gotta look at people’s honesty and their thoughtfulness of what they did and remembering how they did it and what they were thinking at the time too, as. Free information, not free, already paid for it.
I don’t know. It’s free. [00:12:00] You already paid. How do you get the value outta it and how do you make it so it’s, mistake, proof, and how do you should have all these goals of getting, getting behind them. This idea of a culture of accountability. Being something of a culture of blame is no, if you want accountability, do not blame, I guess it’s blame aware.
Sometimes there’s somebody to. And a lot of times no one’s blaming that person more than themselves, but that’s the right attitude for learning. That’s the right attitude about failure. I’ll just say one more thing. In the DevOps world, there’s this mythology around the Netflix, seminary, me and the Chaos Monkeys and all that stuff, right?
They go on with those who don’t know. I’m sure everybody does that, uses these different agents that go around either canceling and turn, turning off services on servers randomly, or disabling services, or shutting down machines or shutting down regions to impose what, to impose failure in their system so that they know that it’s bulletproof.
If they knew everything about their system, why would they? They obviously don’t know stuff about their system. They’re trying to learn and they’re actively pursuing failure. [00:13:00] They want failure as an investment. For them it’s how they get better. So if you’re like most, I dunno if you’re Netflix or Netflix and hey, good for you.
I have nothing to teach you. But if you’re like most of us, sometimes you don’t have to go and investor failure, it just comes right to you. Just don’t waste it. Don’t waste failure. That would be my thoughts on accountability and. Changing culture. There’s some of it, some of the aspects of it.
Does this make it crazy? The idea is you wanna be learning all the time. Cause no one knows anything. That’s the, keep that in mind for when you go to work.
Amir Bormand: Yeah. And I think you made a great point is involuntarily a cost is put on a situation when there’s a failure. To learn quickly, right? You’re trying to solve a problem that you haven’t solved before and I think what maybe a lot of times we, yeah, obviously the Netflix example is very good, is, and I think everyone talks about you’re either succeeding or learning a way that didn’t work.
I think obviously the postmortems are great. I think really what the value is capturing. Hasn’t worked. And I think a lot of times we talk about, [00:14:00] tribal knowledge of, if somebody leaves a company, they’re just not leaving the company of, what’s been working.
They know what hasn’t worked and ha they could guide people to go, Hey, don’t make these same mistakes. I’ve already seen it. And I think a lot of times we’re not capturing that information to go, Hey, listen, there’s a repository of stuff that’s failed. These are all projects that have gone on and these are reasons why they haven’t worked.
If you have this idea and you want to go down this path, just know these are the different, paths that we’ve taken or for whatever reason they haven’t been successful. At least you can maybe go, Hey, I’m gonna improve on one of those. Cuz I do see the opportunity. And I think when you talk about, know, blameless culture and accountability, I think a lot of it would really be resolved with having a process in place to understand what happened.
And have a learning opportunity and everyone realizes, there’s an opportunity to learn. Cause I think there’s a difference between not having the ability to do your job versus making mistakes. And I think there’s, that’s too, that’s such a fine nuance cuz in engineering we’re always putting people in positions to push their [00:15:00] ability to do something.
We haven’t done something novel that, the company needs to be done and it’s not always fair to go. You’re doing something you haven’t done before, and the expectation is you’re gonna get it right quickly.
Paul Kocan: Yeah. I I think that as a leader, if you take that attitude and you’re always reminding, those smart people who work for you, who actually, make all the things happen and you constantly reassure them and you could start with saying stuff, Don’t worry, give your best shot.
It goes, if it doesn’t work, I’ll I’ll take responsibility. You could start with that, but that’s like a local optimization for your department where you really want us to have a company-wide attitude about understanding, they have to understand that the company’s bread and butter, the way it works, every company that matters these days is a technology company.
It used to not be that way, but now it’s, it is. It is relying on technology that no one fully understands and that we have to like, support those brave [00:16:00] people who are keeping it running and trying to change the system so that it can meet tomorrow’s challenges. If you never touched it, it’d probably be okay for a while, but if we have to change it, we’re taking risk.
And then just having that attitude about we’re gonna try to shrink these into small, safe changes. You know that whole idea of a smaller batch and. Really try to work on our ability to restore after failure, right? That’s a good metric to have. How fast do you restore after failure? And then giving people the kinda the courage to, hey, go try, if they fail, recover fast, fail fast, recover fast, and then learn fast.
What do we learn from that?
Amir Bormand: The one thing that’s interesting, Emmy, you mentioned is, you talked about the leadership and I think that. Part of the solution. I think the other fact is when you have people join the company, eventually individual contributors talk and people who have learned that a culture is not really saying what they mean about.
Accountability, empowerment. It’s Hey, listen, they’re gonna want you to speak up, but [00:17:00] really maybe you should watch what you say. Those are common little, convers obviously right now, people being not in the office potentially is a wrinkle, right? I We haven’t even, talked about that cuz that’s a whole different wrinkle.
But in the Office of Old where people were sitting next to each other, that probably happens on Slack or teams, that could happen, is, hey, you’re watching out for the new person that doesn’t know. And we talk about managers, it’s listen, if that culture. And that comfortability is not there for people to actually see what you’re saying.
So you’re talking the talk. You gotta walk it, you gotta let people make a mistake and realize that it’s okay, and not actually then turn around and do something different. It’s
Paul Kocan: not even just in the realm of actually making mistakes that I think that’s, that, and that’s so true, right? So that as leaders we, we say one statement, we’re in a good.
After lunch when we’re nice and comfortable, and then one, and then once there’s the pressure’s on and we’re in trouble and Ted’s are, there’s all of a sudden it’s, it’s a different attitude and there’s a lot more there’s a lot less, psychological safety. But it’s also in the realm of just the everyday [00:18:00] answering of questions.
Do people feel safe? Like when they don’t understand something to a ask questions like and to. Actually not just to ask questions, it’s also to explain the way they understand something out loud. Cause what see is that people will often get in trouble for doing that. They’ll go into the situation, they’ll in a meeting, they’re like, Hey, why did we do X, Y they’ll ask some question that’s uncomfortable for leadership, and then there’s a repercussions to that, and that person’s so it’s don’t ask any question.
Just, that’s the safest thing. Don’t ask questions. Guess what happens? You don’t ask questions, you don’t learn. What’s much better is that let people feel comfortable to make a fool out of you or center or ask hard questions. And and if you don’t have a good answer, just say, Hey, it’s the way it is.
I don’t have a good answer for. That’s just the nature of the thing or whatever, or we’re working on it. But really, encouraging people to. Really understand the whole entirety of what you do as a company and what their role, how their role fits. Otherwise they get this idea that they’re doing a good job or they don’t know if they’re [00:19:00] gonna do job.
They just dunno how to make good decisions. It’s the whole, concept of when we, when we think about having empowered teams, right? In the old days the old days when I first started, there was this idea of. People talk about empowered tes. What they really like is centralized command and control.
Everything’s really well planned out. It’s thought out. You give, centralized command, distributed execution. You give the orders out and everybody does what they’re supposed to do, and you have great results. And I guess that used to work at some point in history. I don’t know when, but it did apparently because it became very popular.
But then people started thinking I want more, empowered teams and stuff like that. What makes an empowered team? An empowered team is not gonna be empowered if it doesn’t have the context of the whole big picture. So you need lots and lots of. Lots and lots of transparency from the empowered team back to the centralized management so they can see what everybody’s doing and understand what everybody’s doing.
But they also have to have a, they have to go the other way too. Like you have to be able to answer every dumb question and [00:20:00] have every awkward conversation with the person who’s on the front line, who’s confused or upset or feels like they’re being put in a bad position. Cause they, there’s a lot, especially in shared services, there’s a lot of feeling like you’re stuck between a rock and a hard place.
I have to do this and I have to do this and I can’t do. So I’m working all night, or I put something off the ground. There’s a lot of pressure and if, but if you have the right context, you really understand when there’s unity in all the work that’s going on and what their true priorities are, it allows them to quick decisions about how to solve for problems and prioritize their work most efficient.
But that requires, again, just this safety that people can speak what’s on their mind and be wrong. Be wrong. Articulating a problem, be wrong about whatever, you can’t create an issue. It’s all in people’s heads.
Amir Bormand: We definitely I was actually thinking, I had, I think on the intro, I had some other areas where you go into, but I think it’s been really interesting talking about really some of the cores of, the psychology of people feeling secure.
And really I think everything I’ve been listening is a lot of it’s around people [00:21:00] security. If you feel comfortable and secure, it’s like a relationship, with your, know, significant other. When you feel secure you may say different things. If you’re not feeling secure in your relationship, you might hold back as you’re like, I don’t I’m worried if this is gonna cause a problem.
So I think it’s interesting that a lot of things we keep coming back to are relationship. I’m not a marriage family therapist, actually, my wife is, so I get a lot of free I get a lot of free help there. And a lot of it is based on the security you’ve been mentioning, secure, feeling secure.
And when we’re talking about holding people accountable, but empowering them, there is definitely, some friction there of how that balances. I think you’ve had some great viewpoints. Final thing I wanted to cover is when you’re looking. Hey, I want to empower people and I want them to be accountable.
How do you keep track of, your initiatives working, right? Whether it’s a company-wide thing or a departmental thing, or however it is are there metrics to keep track of? Is it more of yeah. What do you keep
Paul Kocan: track of actually? Yeah. I tend to focus on, I tend to have a [00:22:00] few different aspects.
So on the delivery side, what I tend to measure is I. I try to have all of my key contributors, the people who really, it’s a dirty little secret when you get into leadership is that, 80% of your work is done by 20% of your people. Just the way it’s, sorry for all those people out there who didn’t know that.
Just true. But all those two, that your top 40%, top 50% of people at least knowing absolutely everything they’re assigned to. Okay. Because those are the people who get named to work on other things. So when there’s a crisis comes up, someone comes to you, we’re having this issue.
Can we have, John, or, move through, or whoever his name is work on this. They’re the right person with the job. And if you don’t know exactly what that’s gonna impact at that moment, in the heat of the moment when you’re asked it, it almost doesn’t help you. If it’s an hour late, you should know exactly what they’re working on and what’s gonna be impacted If you say, Know, the, know the cost of saying yes.
So that’s one thing I track. What’s a metric? If I know what everybody’s working on and they [00:23:00] don’t have too much work in progress, I’m managing how many important activities and everything that they are assigned is rank ordered by priority. So they’re, they know what’s number one priority and if they haven’t been reach a delay, what’s number two?
That’s what I try to do. And that’s, I find that really helps. The other one on just operational excellence is. Really understanding like good practices. Do all of your team know how to do a, like a peer review of their work? They know how to get their work peer review, right? Do they know how to They know the importance of having a fast back out of changes, right?
And they know who to, to who to contact to be able to test the change post back out. That’s something that’s really important. And then I think that the other thing I track, this would be like over a year, is I always try to separate some of the bandwidth for the teams, right?
Is the dealing with technical debt. But technical debt defining a very particular way in the way that Mick Kirsten defines it, which is that which inhibits [00:24:00] productivity, that which is slowing you down. Not, your risks, not your, like technology risks, availability not to it’s what’s slowing people down.
What’s the, what are the main constraints in their value stream of. And you identify those constraints, there’s ways to do that. And then you always be working on taking the biggest constraint and trying to whittle away at it or attack it directly or address it. And if you’re not working on a constraint, you’re not getting better for tomorrow.
You’re just gonna only regress. So that’d be my answer for that. I think.
Amir Bormand: Awesome. Paul, I think covered a lot of ground. I think co couple things we’re on the list was hoping to cover. We might have to do a follow up. I know, obviously kind of end of our time for this recording. I was gonna ask you, I ask everybody who’s on the podcast this question.
But if you could ask a future guest to cover a topic for the podcast what topic would you like to hear about?
Paul Kocan: I think on that, On the concept of technical debt, I think I don’t see enough. I see. I would love to see a, [00:25:00] an in-depth conversation about companies that have been successful in basically addressing legacy applications and either rewriting them used or using, the strangler pattern or however approaches to taking those old applications that still make money that.
Really legacy and don’t use any modern practice. How do you address those? I’ve seen more people fail in that front are successful. So that’d be a topic I’d love to hear about.
Amir Bormand: Awesome. I like that. And if somebody wants to connect with you to cover Yeah. Anything about the podcast touch base with you, how, what’s a good way of reaching out to you?
Paul Kocan: LinkedIn. Paul oca, LinkedIn. I pretty good about
Amir Bormand: finding. We’ll def we’ll definitely include that in the show notes. So if somebody wants to reach out to you they’ll hitch you up on LinkedIn. Paul, thanks. Thanks for being on the show. Thanks for sharing.
Paul Kocan: Thanks for inviting me. I really had a good time.
Appreciate it. Look forward to doing the game. Awesome.
Amir Bormand: That’s it for this episode. Be back again. Different topic, different guests until then. Two things. One, if, some of ’em, they could talk about their experience of,[00:26:00] migrating, especially legacy applications that are making companies money.
I Those are a lot out there. And moving them to a modern infrastructure, just how they’ve dealt with the technical debt. I think that’d be a great episode. Reach out, let me know. Love to have you on. And secondly, if you found the podcast. Share it with somebody else that it’d be awesome.
Also, leave a review on the podcast app listening of your choice. That’s it for now. Until next time, thank you and goodbye.