#2 - Transformational Leadership with Frank Lacalamita
About the guest
Frank Lacalamita, Director of Security, Infrastructure and DevOps
Frank Lacalamita is a software architect and a technical leader in Toronto CA. He has been working on technical transformations in multiple industries over the past decade.
On this episode of PragmaticLead we're talking to Frank Lacalamita about digital transformations. Change management is hard, especially when stakes are high. Innovation requires changes. There is a lot that goes into planning and organizing big migrations, like hiring and training people, getting buy-in from the leadership, managing stakeholders' expectations and more. We talk about our experiences as well as challenges.
Welcome to pragmatically podcast, your hosts are Alex and John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses, check out PragmaticLead.com for more content just like this.
Yeah, we'he had a lot of conversations recently, a lot of them are relevant actually. Frank, in our last chat, we're trying to understand DevOps, we're starting to establish that. And I'm, I'm in a position now where I put together a new team. It's the first kind of platform team at the company. And so while we were handed a number of interesting projects, like unified graph, mono repo, and now they've asked me to step into the CI tooling and those kinds of things. There's a whole organization that's already been established has been working on that stuff. So there's like, it's not like a hostile takeover. But people are miffed. You know, they're like, what the hell man? Like, this is my thing. Like, you have no idea like your heads in your ass.
And I get it. It's cool. I've been the meeting I was just in a moment ago to check in every now and then with the manager on what we call the pipeline team, which is kind of a strange team to have. And he's like, "What the hell are we supposed to be doing?" Like, "You're telling me what tools I need to use?"
So but I'm really interested to see what we're, we're on a good track. You have to be careful on how you talk about and how you gonna change someone else's stuff. And it's not really about me changing their stuff. It's like, how do we work as a team to do that? So you met Alex, where we were lovingly working on a cryptocurrency called chook bucks.
That was supposed to be a secret.
How do I get on this?
Actually talking to you trying to get you to buy some of this new money
For only a small fee
The last conversation we had. It was about how do you establish those tooling patterns and all that fun stuff. Is that still one of your issues or hurdles?
Well, my motivation for the first conversation we had, Frank, was around getting more perspective on how other people think of this the space. You mentioned, a framework you use, I actually talked to a couple of people about it was ITIL and as I understand there's a couple of others,
Yeah, there's SOC.
So ITIL as some people described it to me is is actually pretty rigid. Would you agree with that?
Depends on what version of ITIL. The newest version of ISO actually incorporate a lot of agile methodology into it. They had to adapt to the new world. But taking and taking the rigid ITIL framework doesn't mean it's written in stone. You can create an adapt is what type of processes you want and bolted on to the ITIL framework, whatever makes whatever creates the process in the workflow for your company and teams. You can use it as a framework and build on top.
Okay, that makes sense. AS ITIL evolves, what's your source of truth?
So, I looked at it this way, when I was doing my tech plan, right, the tech plan talks about many items. And this comes from the top right, this is a discussion where, you know, the CIO and the VP of technology have to come to an agreement as to where they're looking what what path they're going down. And just because of my past where I was that person that worked with the C level suite folks, that we would develop these test plans, and that would kind of help develop what your frameworks going to be. Okay. So for example, like You know, if you look under like one of my coffee, it's like management. So what are like? What are your change management structure today? Right? And you know, let's say, what's your current state? And where's your target state going to be? Right? And when you go through this assessment and evaluation, what you end up getting is your roadmap as to where you want to be. So I feel you can use it as your backbone. And then depending on what automation you want to put in, or what agile frameworks, you can incorporate that into that. And that's what I did.
Oh, that's really interesting. So you, you said ITIL has been has adopted agile, or pis to be inclusive of agile,
I incorporate that. Well, I didn't incorporate the ITIL version. Or if I recall, having that's what it is. I stuck to version three, which is a rigid option. And then bolt on the other additional automation and frameworks on top of that.
Oh, very interesting. Okay, well, Thanks for clarifying that. Because I think we are like, we want the we want processes, and we want to add language to how we organize ourselves. And like, because, you know, like, you don't want projects, like we're going to the cloud, like,
We're gonna containerize all this shit. Like, what does that even mean? Like? What? What's the benefit? Okay, and then then that's cool. Well, how are you gonna get there? And I think a lot of companies like we like I, we've gone through a couple of false stuff, false starts, I think, but largely because we didn't have that, like at least some kind of framework to kind of hang the hang what we're trying to call, like, how do we think about the problem? How do we know when we need to ask more questions, you know, like, that part, I think was always missing or what education we need to bring on? Or what talent we need to bring from outside to help us kind of get this this stuff going, and what can we expect long term? And what about our context we're going through some of that now, too, is like, the context in which our software runs is drastically changed. And so some of our architects have taken liberties to take advantage of some of the benefits of using some of the more modern infrastructure patterns, but completely forgot that you have a lot of legacy stuff that needs to coexist here. And so now there's discrepancies and compatibility issues now that they need to contend with and they're building more software to solve that problem are there we're sacrificing decisions in the new stuff to support the old stuff. And it's just kind of tacked on later. Or I think like this kind of thinking, like you said, you decide to front, you know, what, you're where you're trying to go. And then you pick, I think a framework is a very strong like, I'm actually working with one now it's mostly I'm using the pragmatic framework, I didn't realize was actually a product persons framework. I'm like, Oh, yeah, I'm a Product person. That's why I have these problems. Before too much, Frank, before too much time gets away from us, I'd really like to, you seem like a transformational person. To me. A lot of the stuff that you've been through has also been seen transformational in nature. You described conversations with IBM that you've had compares companies that you've couple of companies that you feel grew and you've had an effect on. So Alex, and I want to and Alex, thanks for, for making some time to meet with me also, this afternoon, I think it's gonna add to the, to our conversation. transformations hard, right? Like, it's hard. It's hard to think about, it's hard to kind of plan like, really big transformational things. But then there's a lot of nitty gritty like, oh, cool, man ideas are there, you know, Sunday, business wise, you know, we're gonna have this these great things. But then like, you have unconscious people around you, you have education problems that you have to solve. You have, sometimes people have strong opinions, and they're pushing back and kind of getting in your way. So those are some of the things that we're hoping that we can chat about.
Yes, also, transformation is unavoidable, right? You want to have that you want to have change, you want to have innovation. So it's hard to do. And so that's why it's a really interesting topic to, to deep dive and kind of talk about that with with you.
Yeah, one of the things I always tell all my colleagues is that you have to embrace change, because this is the era we're in, right, your job, and it never stays the same. Right? Since day one. It's the only industry that every six months something is changing, and you always have to adapt. Right. And that's always been my focus for a lot of juniors and new new people coming into the industry is you have to accept change. If you don't, you'll be lost. Why do you say that? Why do I say that?
Alex, and I know why you say it.
Oh. So if you think about it, you know, in my in my 19 plus years, right? I used to be a Unix guy. Right? And I always think Unix is a free way the future and I will be happy being a Unix person. And then you certainly do the same be the open standards. generations are coming, he started noticing the wave of open the open standard, and you start realizing that, oh, wow, all sudden, you can do so much more with these open source projects, the evolution of that has just exponentially just skyrocketed. And now the Unix world where I came from, it was all proprietary. So if you don't accept that change, you will be that IBM or who done a mainframe, and he will never ever adapt and grow. And that's where I saw that. There. So there's, um,
yeah, so, okay, so as, as an individual, you're expanding on your skill set, right? And you're exposing yourself to new ideas. You said something that I don't know is, I know, I'm interrupting you. But you use something he says that you can do so much more?
Correct. Right, that
directly speaks to productivity. Yeah. Right. And that like, so it's easy for you to convince me or Alex, on our call today, that transformation is good, because we've seen that right? We've seen those benefits?
Well, maybe, maybe not. Maybe I'll say it? Well, it's expensive. If it ain't broken, why fix it?
Right. Like if they face
the reality of a business time to market is everything. Right? The faster you get your products out there, the faster ups, revenue, profits, and all that, right. If you're always waiting back on the proprietary products, the you know, the old legacy platforms, the open standards is like, Hey, I can go and select, I don't know, let's say a DevOps tool, I don't need to go to IBM and get a license and go through that entire process of procurement. When in less than an hour, I can have an environment up and running. And then all sudden, I can start shooting with my products. But it's not generation is that evolution is what kick started, you know, is high in the market, the automation, the the the push to, to get the cloud, all that it all started from there. And that's why when I look at that, that's what really was a driving force. That's why if you look at companies like IBM, they suffered, because they didn't follow, they didn't try to adapt. That's why they purchase Red Hat because Red Hat was the leader in that at that time. So you see, it's all around us, if you don't realize that you're in the wrong industry, to be honest. Like you shouldn't be here.
So this the thing that I'm the thing that resonates with with me and and tying this back to transformation is when we're going through complex transformation, we have a lot of stakeholders that are the stem outside of the our immediate audience of technical folks that can hang in the conversation, right, we're using language that we're accustomed to, but sometimes we also have are accountable for representing the business value, reminding ourselves reminding our team and our colleagues, and probably our CEOs as well. This comes up often, like why are we going to the cloud? Why do I have to invest in that if data centers was not good enough? Right.
Right, like that makes sense.
Yeah, exactly. So the other aspect to this is, when you when I used to talk to in my previous role as a consultant to the C-level folks, the big ones were "How much does it cost me?" And "How fast Am I to get my product out there?". Because at the end of the day, they don't want to spend money. And they want to, they want to get as much profit, right? And that's their goal. So when you look at Cloud, really what you're doing is you're reducing your datacenter costs to but it also reduces your offset in a certain degree. Because now you don't need to pay for someone at a data center to manage it. And that'swhere the the C-Level folks are looking at it. They're saying, I don't need a 500 IC (individular contributor) member team, I could probably run with half of that. Because now I'm going to remain a service model. I'm starting now all I need to do is develop the automation tools that interact and integrate with the managed services now. And that's where the transformation is like, Oh, I'm a sysadmin. Well, not more, you know, an SRE, your site reliability engineer, right. You don't manage systems anymore. You're gonna manage tools that do automation. That's everybody's jobs are transforming. It's not just a business. It's not just the technology. It's also the people job.
So what, what signals do you see, what pain points do you experience to approach transformation? When you see there's an opportunity, there's a need to make a change? How do you approach that?
So, as a previous company, I assisted with a lot of transformational programs. And it always talked about the three pillars, which is people, process technology. And those are the three pillars you attack. So from a people perspective, you have to evaluate the individuals, what their jobs, what their roles, responsibilities are, once you have that, you start looking at the processes, what you have in place today and where you want to be. And then the last part is what you have today from a technology perspective, and where the business wants to go. Because the technology is easy, that's a rip and replace. That's how it is the process and most people are is what is more difficult. And sometimes you need to re educate a lot of the individual because their jobs are going to change, their roles are going to change, or they may not even have a job to go. The process is kind of the glue between the business and the IT, because you want to put in enough rigorous processes in there for like audit trails. But you also want to have the flexibility to help the business push products and releases and, and whatnot. And that's where the whole Transformation Program comes into place. Because you're going to disect, basically the company and how it runs. And then with all of that information you assess, and you start saying, okay, where do you want to be? Because the business wants you to start pushing out, let's just say they want to do 500 releases a month. Let's use that as an example. And the icy votes are like, well, I don't have the manpower to do that. I don't have the toolset to do that. And I don't have the processes that will allow us to execute that then. So then you start breaking that down. So you're like, Okay, so you're here today, and you want to be fully automated? Or do you want to be maybe, you know, semi automated. And then you have a roadmap that will say maybe by the end of the year, you'll be fully automated. Right? Because you will be able to flip the switch in one night, because it will take time to educate your staff, your your your it. You mentioned people so excellent way to break it down, by the way, because it really those are I think the big parts, I think the for some folks, you have a business team, they might be a stakeholder, someone maybe in the process area, or they're kind of driving.
Let's talk about like people have you have you gone through Have you had to kind of so you shared a story with us were with me, I think the last time last time we spoke about how you were selecting automation tools and starting to bring in new processes. And I suspect that hadn't affected that. Did that have an effect on the people in the organization?
Oh, yes. So an organic? Me first, let's call it 1.0 there was no governance is every DevOps essary thought they had the the accountability and responsibility to pick and choose what tool sets they want to implement into the company and use it for themselves.
It wasn't was it like a per team basis that they kind of solved their own problems? Or was it it was across the board?
Okay, it was across the board. So developers wanted their own toolset. Yes, I read DevOps and no one talked to anybody. And you could imagine the the amount of complexity, I call it complexity that that was established. Right.
So what did what how do you describe Can you describe complexity that
sure. complexities, yes, is basically under simplifying your your organizations toolset, technology people. So you may have multiple roles that are redundant, you, you can have technology of having multiple software or products that are doing the exact same thing. So why would you add that, you know, it can even go as far as the infrastructure, the design that was chosen, you can have like, multiple, I'll call them in Amazon's will become vccs. Right? So those are the networks, right? The court, right? You could say, well, instead of being a multi tenant is architectural infrastructure is it Singleton, right, and then also not becomes complex. That's where it comes. So by reducing your complexity debt, you're going to a reduce your effect spending, right. And plus, you're going to by reducing office spending, you'll also reduce your, unfortunately, your staff, your people, because you won't need them as much. And as well, it stabilizes the environment. Right? You start adding more stability.
So thank you. Yeah, definitely well described.
Yeah, never heard that term before. Yeah, that's interesting.
If I could kind of rephrase it, it sounds like there's, there's some companies, I think, I don't want to speak for Spotify, but I think they've, they've adopted what, to me if I could from the outside in kind of, um, if I could put a label on it, they've used kind of like, micro service front end or front end as a service kind of model. And that mindset is there, okay, with complexity debt in this and the shape of, let's say, I'm using the same or different versions of similar libraries are being loaded in the application at one time for the sake of allowing teams to be kind of self organizing, and kind of committed to like selecting their own toolset. So there, it seems like they've kind of governed it a little bit differently. Is that kind of a similar? Or is that kind of close to?
Kind of, kind of so if you look at it from from their perspective, they will take on complexity, correct? Mm hmm. But at the same time, is their effect spending, you know, over the top? are they spending more than what's the one coming in? Right? Are their accounts payable, overcoming their accounts receivable, right, or the stability issues in the environment, so it is hard for them to keep up to speed with their security patches or the releases, right, it all depends on what level of complexity you're willing to, to, to withstand, to accept, right. So for example, at amp organics, you know, they were pushing only eight releases a week. And if you're lucky, it was really four, because the other four most likely failed, right. And if you start, if you start, you know, unraveling that onion, you start realizing why they're, you know, they're only pushing eight a week when you have over 125 clients that you need to push these releases to. So you can imagine, on a one year basis, how many releases are actually pushing out, they're only pushing maybe two, by the time they're, they're completed around, and you'll never ever complete the round, because by the time they finish their first round, you're overlapping with their second wave will release it. So when you look at that aspect, the complexity, the complexity that it was established in the environment, did not help. It didn't resonate in a healthy time to market for the product team or for the business.
I see what you mean. So at what point do you see a need to debug issues like that? It's not like you everyday going through like, oh, how many builds we have? And like going through all the possible issues, right, at some point, it has to come up. So at what point? Do you start looking at issues like that and debug them?
So when I joined organic, I had to assess the environment, right. And I did the whole transformation. And I got a budget, right? So receive the budget, and I look at the price tag, and I say, Oh, my God, I this is crazy, right? Like how can you spend, you know, like, over 75 k a month, on your AWS? When you would like bathroom? So used to be an architect, you know, it's like, I can do this for half the price. Right? And then you start again, sort of poking at other things? Like, why are we only doing a release of the week? Like, this is ludicrous? Like, how can you have a product? And how can you have clientele, you know, happy accepting clientele, of these features, which they're waiting on for a month, like, things just didn't add up anymore, you know, and then you know, you have your, your stability issues. So, you know, because they're not pushing the releases fast enough, the application has a lot of fun. So then you have stability issues, right? So then also, then, you know, your SL A's are starting to get affected. So it's like a domino effect, right? Everything you look at, you'll see another issue pointing in another direction. So when you start, you know, reviewing and reverse engineering the environment instead of looking at it, and you're like, Okay, so there's time for change. And when you ask the individuals, you know, who architected this, who is the architect, Nobody puts up their hand because there are no architects. And that's where it starts stemming from a governance perspective. So as part of my solution, I had to hire a architect or cloud architect, right, to help fix the problems to help read, unravel all the issues, sorry, so to simplify the environment, so to speak. So that's where the complexity that comes into play, I simplify this environment, I resolve my costs, my effects, I resolve my stability issues, and I also resolve my, my releases. Right? And that was the program. It was basically how do I reduce how to increase my stability and how to and plus all these securities involved in US 30? How do I not affect security, and that was the program so we had a sense a six month project that we attack from all different sides.
So this is great, because you were kind of telling a story and not exactly order. I think we just went right back to the beginning of identifying transformation. So I also appreciate it sounded like you had a number of KPIs that you were looking to improve based on prior experience. That's right, which is also quite valuable. And then it also sounds like part of the transformation was identifying new roles that were not that did not yet exist.
Correct. That's exactly it. That's right. Because that comes to the people. So when you started looking at assessing your the people of the organization, you start noticing the gaps. And then you have to figure out how to resolve those gaps, how to fill those gaps. And like I said, in this situation, there was no governing body for the technology. And that's where it is.
So you added a new role, an organization that's probably never written that job req before? Correct, right, what would be your strategy? How would you coach someone kind of through that part of the process? How do they know they're asking the right questions?
Sorry, from what perspective?
So they had they've never had, let's say, companies never hired a cloud architect. How do you know how to draft that job req?
Or it's easy for me, I used to be a cloud architect. So for me, it was really simple.
So just be a cloud architect.
I used to be a cloud architect. So I knew what was missing. So in my case I basically I went to, you know, the the CEO, and he says, this is your gap. This is the reason why you're here today. Right. And it's like you you've completely overcomplicated your environment. And everybody thinks they have a stake. Everybody thinks they have their own piece of the game of the puzzle. And it says that needs to stop. successful companies always have a governing body. And that's how it works. I didn't go to this right.
How did you back that up?
I just backed it up with my experience. So if you look at a lot of the enterprise companies, you know, you know, they're all take for this the the IBM, the Canadian tires, blah blah, the CGI, and then there's the payment side, right? It's basically, this is how it works. You have architects in the main seat, so they understand what needs to be done there the seniors, and whatever it's right or wrong. You need a title associated with that, with that responsibility. So and I had to educate the company on that. Because basically reason their hands the whole what happens if he makes the wrong decision. And that's okay. It's okay to make the wrong decision. But I want someone held accountable for that wrong decision. They're not gonna get fired. Right. But I just want someone to have their name tied to a decision, because that means we move forward.
Yeah, that's interesting. So it's like, that's actually really interesting. Because it's not just about centralizing control. It's about centralizing iteration. If you have if, like we had somebody that was accountable for a specific aspect, you have a place to provide feedback, at the same time that you know that feedbacks going to be applied consistently. And it frees us in the organization to think about other things.
Correct. Exactly. So this also comes from a PMO, and I'm not a project manager, I'll never call myself a project manager. But an F organics, I had to implement a PMO framework on top of the ITIL. And that against them for because decisions are being made, but I keep on questioning them. I would say, why, why is this a high priority? What is the benefit? So it all come back from it stems from the PMO. So you have an idea. And then you pull in the technical resources, like the architect and the SMEs? Or the you know, the DevOps, SREs, the sysadmin. The developers, they are contributors to the solution. But at the end of the day, the architect is the one that signs off on what the solution really is. And he may go with your your suggestions, or he may not, but at least it gives people a sense of direction, from a from a project perspective, right and accompany and analyze things. I fthings go south, that's fine. I get people saying I tell people, that's fine. But I just want to make sure that everybody came to an agreement. They we work together for a solution, a project, and we have a signature on it, and we can move forward and it's all done moving forward. Right, and not wasting people's time with other priorities which are not required.
So important. So speaking of people and transformation, so you can then seriously one of the kind of sizes that you have to convince the executives right to have this transformation, but you need buy in from me that Yeah, you need you need buy in. So you convince everybody but then on the other hand, you have people and like you said, it's gonna affect everyone, right? jobs gonna change, some jobs gonna disappear. So how do you how do you convince people who actually got to work on on this transformation to actually buy in and be part of it motivate people.
Because every individual, and again, it comes back to is will they accept change, will they adapt to change, some individuals will not their heart set on their roll, and they will not want to adapt. And you need to figure out as a leader of who you know, will leverage the the change the world of transformation, and who will not. And that's your job as a leader. So you will way ahead of time, after you've done your assessment of the people, you'll understand who is willing to learn and who's not. And it's unfortunate is that the ones that want to learn, you're going to, you know, push training, you're wanting to have him, you know, incorporate into the transformational program, be a part of it, because that's what's really important, right? A lot of folks be if you're not a part of the solution, right away, they will go the opposite way. Right, they're going to be against you. And that's where the key, and you'll find most people, when you when you do the assessment, on your org, you know, there's the folks who want to be part of it, and you will, and you'll ask them, and you'll see a grow will grow themselves, which is a spectacular thing to see. And the folks that aren't, is basically, unfortunately showing the door, and you replace them with someone else. Like you have to have that cut throat, you know, attitude when it comes to those individuals, because you have a goal that you have to meet. And if they were running the business, right? Like, it's not personal, this is all business.
So after folks have a chance to understand the bigger picture, the vision, why the change is planned. So all the benefits and value and all the work that the organization is putting into education and kind of all this time and investment in people and if they still are not part of the idea or didn't buy in, I guess you have to make tough decisions at the end.
That's exactly it. Like, I'll be honest on here's a great example, on one of my teams, you know, either I call them, they're like tier one support, right, though your traditional upset like a knock, okay. And you know, their hardware support, and they do very basic tech support. And so my manager, who they report into, we sat down, and I basically told them, your jobs will be, you have two choices, you always can see what you're doing today. And knowing that you may not have a future, or B, you may learn something new and adapt, and you will have a future, right and use your options. Right? I'm being very honest and cutthroat. And that's who I am. And they actually adapted, they wanted to learn the automation tools because they were hungry. And those are the people you want. Alright. And today, they are like my SRM team now. Right? And they haven't left. And they're more than happy. Because now they learn something. They're they're, you know, they're growing. And even from a personal perspective, I'm happy because we can actually move into another company if they want to leave because of their opportunity. I've done that for them. I helped them. Right.
Yeah, one example at the previous company I worked at. QA engineers, quality assurance, they had an expiration date on that job title. So they had to move to be either as software engineers or move somewhere else. The company made a decision, we no longer going to have QA engineer. So that was a similar kind of situation. And most people were willing to go through the training and study, and they had all the support they needed. So was most of the people had kind of success through the transformation.
Sounds like there's some nuance as part of the proposal. Do you also lead with like an education budget or proposal for continuous learning for the staff?
So was the career growth, during my one-on-ones that I have with everybody, including sysadmins, is all about what their career growth and vision are in five years. And I basically work within with a basically a career program. So, you know, there's, there's there's like Linux Academy that we've that I've worked with, that we kind of put up a plan, if you want to go down the DevOps path, these are some of the courses you need to learn, right? And these are the tool sets we're going towards now like Ansible, learn Ansible, you know, and you know, once you complete that course shot, you're gonna have a shadowing program. So you'll shadow people, right? It's all about that. And that is another aspect. But that is like a leadership manager titled world, right? Like, that's your job is to help your team grow. Right? Yeah. Like, it's from a transformational perspective. You know, that should be what a manager does is to ensure that his his squad is up to speed, you know, that the new responsibilities that are coming down the pipe that they're prepped and ready for.
So transformation also has an effect. Sometimes parts of a company will change. And the form and function of that part of the company might have an SLA with other teams and groups, right. And so yeah, you can't always keep those same contracts, those things are going to change. And you'll have an effect on other parts of and sometimes you'll discover an effect that you've inadvertently created, right, going through transformation, like, Oh, right, we forgot to have a meeting with with this group over here to let them know, this was changing. Oh, geez. Right, this, this was some kind of old feature that look, you know, we haven't rebuilt it. And it's something we'll have to get to eventually. But for now, we'll have to make some concessions. Talk. Can you talk to us about that? Like when How do you address your stakeholders from an applied perspective, so the people that depend on the team that you're transforming,
the interesting fact with Ample Organics to that because they had no processes. And they had no internal SLA, it was kind of a Greenfield for me. So it's basically working with your internal customers. And it's to see where, what their requirements are. So my customers, they were QA, my customers were the development team, my customers were the help desk or customer service representatives, right? product team, those were all my customers. So you have to establish the requirements from them. And everybody's different. But also, it's also educating them on how the requirements work with processing, you know, you know, a lot of them are not used to that you have to open up a ticket for someone to do work, right? A lot of people just use a tap on someone's shoulder and say, Can you do this? Right? And it's about educational priorities. Because when you start hitting a ticketing system with SL A's and priorities, then you start realizing that I can't tap on that guy's shoulder because he has five other priorities he's working on. So it was all about how you educate the company on what their expectations are, and how I can help them. And it's the level set. Because I was the owner, I am the owner of the operational side of the fence, I was able to dictate what the SLA from my perspective, what I can provide to them, right, I can give you a response in four hours, I can give you less than that. I took control of it that was mine. Whether you're looking from a from a external perspective, that's totally different. You're looking at the product team, right? The product team are the ones who own the SLO's and SLA for the client. Because they know them better than anybody they're supposed to. which is different. And that's where the negotiations happen. Right? If they want a, you know, a five nines SLA, how's he like, sure, pony up the dollar. And I can do that for you. Right, like, that's what it comes down to. So that's where the negotiations happen. I guess. It's not a simple conversation. It's something that you have to understand what they want, and how I can provide them a solution that we can meet somewhat halfway, hopefully. So for example, I'll say like, the customer service team, you know, they never knew about Incident Management. They didn't know about, like, you know, if I needed someone to help, I have to create a ticket and assign it to them. Versus I can slack them, right. And say there's a bug, there's a problem, like a lot of that. And then when you have the compliance coming in, like your sock, your sock compliantly, that also Chi Bosch is all of those anti processes that you have in the environment, because it's all based on your controls.
You're using a requirement as a means to create motivation for adoption.
Yes, that's right. You got it. So as part of my roadmap, you know, I want to be SOC compliant, I want to be SOC one compliant. And when you have the buy in from the executives, it kind of just filters down, it rolls down. Because you're enforcing, you're educating people who say, we're doing this because of this. There's a reason why, and it's a good thing. Right. And it's, it's something for the company, it showcases to the world that you know, this isn't just a startup, this is a company that has processes in place that, you know, a devoid company has signed off on an amazing accomplishment. So that there is what is a tool I used to help move things along.
Do you find that the your message for describing the context right, providing context to for motivation? I think that's exactly that's a lot of what we hear today, right? Like if you're trying if we're trying to keep people engaged, stifle burnout, go through transformation, as we provide people with the why why should you care about this? What is it what's in it for me, to commit to, to commit to these ideas to commit to my team to doing this work, but that's not exactly the things that I actually think are going to drive the business forward or improve the productivity of my team? So do you find that sometimes you have to tailor the why a little bit for each of these groups?
Yeah, I kind of chuckle at that. Because when I own the the operational side of the fence, the infrastructure and security, I have facts and evidence as to where we are today. So if we are up in the middle of the night, because of stability issues, during the day, I have no staff to do work. So the product team, how am I able to help you push products to the preview or the QA team environment for your customers to test? If my people aren't there, right, QA team? How can I support the automation tools for your job if my guys aren't there? So and then you go to our team, my own team? And I say, Do you guys want the quality of life, because as most people who focus on quality of life more than anything, and you focus on that, because that's what people, that's what they want. And I say to them, if you want quality of life, trust me, the Transformation Program is going to help you it's going to reduce the stability or increase your stability, it's going to reduce your effort in the middle of the night. And then you'll be able to be here during the day to do not the day to day activities, you'll be able to do some more innovative projects now. Right, because now you're offloading a lot of that to the toolset. So you're freeing up your time. So you're trying to educate in the the win win win situation across the board. So it's from a support perspective, right? And it's also from a service perspective, and it's also from a quality of life. And that's when you have to educate across the entire org.
So the last question I have, what advice would you give to a new manager or CTO, who is facing transformation changes? Final advice?
Hire me :) To be honest with you, your tech plan, and your roadmap is your foundation to your transformation, because you need to focus on those three pillars, right people process and technology. And that encompasses with your roadmap, and your tech plan. Because your tech plan will tell you where you are today and where you want to be, that will then feed into your people. Can they do that? Or do you need to you need to implement or hire new people? Or do you need to implement new tools from a technology perspective? Or are you missing a process that it doesn't exist? Or do you need to improve on a process that is what is crucial to any C suite, individual not position, that is the foundation, they need to spend time to figure out where they are today and where they want to be. And that's how it works.
That's great. Thanks.
So Frank, one thing we'd like to invite you to do is, um, you know, is Can people contact you for what reason? Can they contact you? And how can they contact you? And, and do anything? Yeah. Do you have anything that you're up to that you'd like to let people know about?
Cool. So you know, my personality is I've always been a problem solver. I'm always willing to help people out. They bet just who I am. All right. And it's always been there since day one of my of my tech life. So if people want to contact me, you know, they can contact me on my other day my email address or how do I
However you want?
Sure they can contact me through LinkedIn is probably best way. So Frank Lacalamita, the other part is I'm actually working pm a transformational presentation for HashyCorp. They've actually asked me if I can be a presenter for them in the next couple of weeks. Just go through my transformational program and,, hopefully help some someone else. I'm here to help out. That's who I am. I always will be. I love helping people.
Well, that seems pretty obvious to me, Frank. Even you, you're willing to entertain my my rogue LinkedIn message.
Hey, that was cool. That was interesting.
LinkedIn is awesome. You can reach out to people anytime and just get in touch.
Yeah. And, you know, people just try new things. Just don't be afraid. This is a world of of innovation and transformation. Have fun. That's the key. Have fun with it. There's no right or wrong. It's making sure that your end goal you meet your end goal.
I really appreciate you mentioning the having fun part. Right? Because we're we spend some of us get really stuck in being right. And we forget how to have fun with our with our craft and our work. So good for you, Frank.
Thanks for tuning in to the PragmaticLead podcast. If you found this conversation interesting or helpful. We would appreciate your feedback. If you want even more content like what you just heard. Check out pragmaticlead.com. If you have a story to tell, send an email to firstname.lastname@example.org and someone will be in touch. Thanks again.