The Process of Automating: Teams, Workflows, Success

Dayle Hall: 

Hi, and welcome to our latest edition of Automating the Enterprise. I’m your host, Dayle Hall. This podcast is designed to give organizations the insights and best practices on how to integrate, automate and transform their enterprise.

Today’s guest is a tech veteran with over 16 years of experience encompassing all areas of integration and automation. He had beginnings in the IT organization and has grown his presence and responsibility in this company where he has a massive remit now, and he’s worked his way up the career ladder as now the Atrium’s Vice President of Technology. We are privileged to have on our podcast today, Leon Kallikkadan. Leon, welcome to the program.

Leon Kallikkadan:

Thank you. Great to be here. Looking forward to this conversation.

Dayle Hall: 

Yeah, me too. So before we jump in some of the areas of your responsibility on the topics that we’ve laid out for today, give us a little bit of background on your experience within Atrium. And I wouldn’t call it humble beginnings exactly, but you did start pretty much at the ground floor in the IT organization. So give us a little bit about where you started, how you’ve grown, and then just let us know what it is that Atrium does as an organization to give some context to the listeners.

Leon Kallikkadan:

Sure. So I started at Atrium as a traditional IT support helpdesk, if you want to call it. I was assisting end users with break/fixes like, hey, I have an issue with my computer, let me run to your desk and help. So I started there over 16 years back, like you said.

Over the course of those 16 years, I’ve had the opportunity, I’ve been given the opportunity, and I’ve been entrusted with leading and working on various projects. I’ve never really only focused on traditional IT like networking, hardware security, those have been areas of keen interest to me, but I’ve also been exposed to application support and application- and so slowly, but steadily, I got access to more technology projects.

And the leadership team at Atrium entrusted me with growing out my team. So every time there was an opportunity to create or to take over or lead a team, I grabbed it with both hands. And in 2020, we launched our third team, which is the automation team, which is responsible for digital transformation, so as to say, and helping with efficiency. And then earlier this year, we launched our integration and apps and integration and web team. So four teams under me. So now I oversee- I’m no longer the IT guy, traditional IT guy, but now I oversee, I have four teams under me and four leaders under me that help deliver all end results to the business.

Dayle Hall:

Right. So that’s interesting. So you have these four teams now. And correct me if I’m wrong, it’s traditional IT, business apps team, integration and web, automation and digital transformation. Is that correct?

Leon Kallikkadan:

Correct.

Dayle Hall:

Right. Okay, so you have these four different types of teams. What I like to do on things like podcasts, and people that are listening, is give us some background as to why those four disparate teams, but more importantly, how do actually you- what are the projects or initiatives that you have where they work together?

Leon Kallikkadan:

Yeah. So I intentionally carved these teams out so everyone can focus on their core skill sets, right? Every one of them, every one of these teams has their core set of applications or technology that they focus on. They are deemed as subject matter experts, and they bring immense knowledge and value to the table. Where they start working together is that’s where- especially over the past year, year and a half, that’s where I’ve just been sitting back and seeing all four of them develop and become such great team members where they’re starting to collaborate with each other.

Like before we start a project, we have this part of our tech leadership team, which is my leadership team, we have conversations around a project that we may think that may have an impact organizationally, but also might have or connect to other teams. So it’s done in a way where information is shared, the possible outcomes are shared, possible challenges or possible impacts to each other’s teams. We try to see how the four of them can support each other and obviously, myself as well. But we all try to see how we can support each other like, hey, can we present a fresh pair of eyes, or did you think about this? Try to reinforce, try to challenge. I love people who challenge each other in a respectful way. So it gets us to a better project outcome or a better project infrastructure rather.

Dayle Hall:

Yeah. I love the concept of having discussions or looking at projects that may, on the face of it, not seem like they impact everybody’s or other people’s responsibilities. But I think with most IT, most applications in data today, I think we’re all realizing there is a big impact on multiple people, on multiple organizations. One of the things that I’ve learned from a lot of these podcasts over the last six months or so is one of the key pieces of advice that I’ve been given from some of these IT leaders is start talking early, start sharing ideas and get feedback before you make selections, before you go to RFP, before you look at technologies, and make sure everyone is focused on what is the true outcome and exactly what some of those implications could be. And I think the more you talk up front, probably the smoother that implementation could go. Do you find the same with your teams?

Leon Kallikkadan:

Absolutely, yeah. It’s extremely important, especially because everyone’s in their own lane, it’s even more important that those channels of communications are open, right? And you don’t know- in true transparency and true impact, you need to know, you need to have these discussions way before you get into a project, and then try to figure out what kind of falls on other teams.

The other thing to keep in mind is, the other thing why it’s important is from an individual team bandwidth point of view, right, so you might be- all four teams might have their priority list laid out and it’s important to understand what someone is working on right now and how your project, which might be very important, could trump something else. So it’s important from a bandwidth, from a scheduling and from a resource point of view that those conversations happen early.

And over my 16 years, what has really, really grown on me, and I’ve really matured, is the need to understand what the expectations for the business are. A business does not want a product where you start saying, well, this is not part of my responsibilities, this is part of the IT responsibilities, so speak to someone else. So from a business user experience, that is not the experience I want to show them, or I want to give them, so I want them to interface with one IT or technology team. And what happens behind the curtains, what happens behind the scenes is our own workflow, our own communication that brings us to success.

Dayle Hall: 

Yeah, no, that’s a good piece of advice. So if we look at a couple of areas that are very hot in today’s market, or very hot around IT requirements, there’s this concept of moving from more developer-led interactions to more low-code, no-code, very popular out there, analysts talk about it, we talk about it. And the belief is that this enables you to support the business better, you need less developers, less coding.

Now there’s some things you do need, still, that level of coding. But if you think about that as a concept, low-code, no-code, lots of applications, you have these four teams, how would you approach a project that is, well, as either supporting the business so it wasn’t a lot of heavy coding or developer? How would you go into that project with those four teams? Walk me through what would be a good process, how would you assess it, how would you move forward, who would own it.

Leon Kallikkadan:

Yeah. So I mean, all good questions. So when we get a project, what happens is- we’ve kind of matured as an organization as well. Now we have a repository or some sort of intake process where anyone can put in a request, and once that request comes in, at the surface level, we kind of vetted to see if it has that importance and what is the level of request. Based on all of that, we partner with our project management team that helps us take those raw end user requirements and convert them into business requirements. So once those business requirements are written out, and those business requirements look very, very different than the initial request, those are more thought through, there’s user stories, there’s various break-ins, there’s additional phases, or this is a must to have, is it a good to have, things like that. And then that is brought over to our team. And then that’s taken over by an analyst who converts that to a business technical requirements.

And that’s when we start solutionizing and look at what the actual application or what we’re delivering is. We do not just solution on the fly. That is a very, very dangerous game. And as a business user, they listen and they like, oh, this is easy. But it’s not. There’s a lot more that happens behind the scenes. So we’ve tried to move away from solutionizing on the fly to now taking the technical requirements, and then that kind of leads you to your solution or your design and what needs to be done to build that application out.

Dayle Hall: 

Yeah. Given what you said around trying to make sure you support the business, don’t solutionize on the fly, so you’re probably meeting more with not just your IT leaders, but with lines of businesses. How much would you say the requests for support new applications, different amalgamation of data, how much of the requests now is being driven by your lines of business and how much is you, in the IT organizations, thinking, this is data, these are things we should provide directly to the business because we know it’s valuable? How is that mix?

Leon Kallikkadan:

So initially, it started from me and my leadership team, like pushing, trying to get the business to make a- the business needs to be made aware, right? That’s the biggest challenge. If the business is not aware of our capabilities and what’s in our toolkit, they never know, those conversations can be had in a vacuum. So we started engaging, we started going to our user population. We started talking to various teams to understand at a high level, what are some of the challenges that we have, and then how this team or the combination of this team can be of assistance.

So it takes time to build proof of concept, build out those applications and present that to the business. But once that is done, you need to start getting the business to be more involved in these conversations. So it’s like, a, you show them what you’re capable of or you’re capable of doing, and then start having constant conversation with the business. And something we developed this year was a conversation with a business leader that I had. I was like, tell me about this process, what is it that this process does, and why is this not happening over here? And it led to a good conversation that we built out of POC for them to see. And now that is definitely helping and has given the foundation for us to do a lot more.

So as you start having more of these conversations, this becomes like the business itself is going to ask you and challenge you, hey, can you do this for me, can you do that for me? It’s like, plant that seed with every business with the business leader, get them to start thinking of automation, and your technology team has just more than a traditional block and tackle or support, there’s more than support.

Dayle Hall: 

I definitely hear a similar input from other organizations now, which is, as you said, go early to the functions, the lines of business, make sure that they know you’re there as a partner. And then chances are, a, there’ll be less frustration because they will know that you’re in this together, and then you can actually enable them to be more successful, which I think I do believe there is- IT is having more of that shift now of being less of a blocker to the business and being seen as more of a facilitator, but I think that comes from different things. It comes from you and your team and how you approach things. It comes from the people and the processes you put in place, and also clearly, the tools, the platforms, the things that you select, the things that you pick to make sure that you can enable the business.

Leon Kallikkadan:

Yeah. I would just add that for us, this conversation has now changed to, how can IT be an enabler of revenue? So for my team now, my challenge to them is, I want us to think differently, I want us to focus on initiatives, focus on requests, identify opportunities where the broader IT team can help more than just, hey, run things efficiently. No longer is that the case. We have access to all the data. We have access to all the technology. We understand the process. We know, from an operational point of view, we get tickets, so we know that people are having issues, we understand what’s happening behind the scenes. So how can we use that data to present a solution to the business and say, look, this was your process before. With our recommendation, now your process can go from A to B. And in the process, you can save X, Y and Z. Or let us try to bring this data stream into your workflow so you have better visibility or you have more capabilities to sell or whatever it is. So we’re trying to really change our approach from just not being in block and tackle or a traditional IT team to be more revenue enabling.

Dayle Hall: 

Yeah. I think that’s a great approach. If we think about- just before we go into the processes piece and the tools, but if we think about the people and the management side of it, there’s- obviously, you have some processes in place. You’ve talked a little bit already about getting early to the lines of businesses and the business leaders, which I think is great, and you talked as well about getting early in the process with your own teams. But how do you manage with the lines of business? And how much time do you spend for planning, discussing versus, actually, the building, the execution, and then the ongoing testing and your backlog, how much do you spend there? And what are the processes you have in place to make sure that you’re successful?

Leon Kallikkadan:

Right now is the best time, right? So as an example, so we start all our project planning in the next year, all the initiatives for the next year, we start having those conversations now. Now in the past, I used to make the mistake of not having these conversations with the business. I used to have a 30-item project list for next year, and I realized that that is not the way to do things, that is a successful failure because you’re trying to set goals and you’re trying to work on things where the business is like, we don’t necessarily care about those things, or we have these issues and you’re not working on those issues.

So we start there, we have these conversations with the business, we seek input from the business before we start something. And then we partner with our project management team, who lays out all these projects with the businesses, with the partner group, in this case, in our case, and we prioritize. We look at which of my teams is going to be the most utilized, if it’s an automation or an integration team, or it’s a business application team. And based on the priority that the business has deemed, we create a map as to what all the effort. We look at which projects start at the same time, where can we move it. So we go through the entire process of vetting that out, we put projects as high, medium and low. And we commit to, you know what, we will get to all the higher projects. So based on that, we have this dialogue with the business.

In terms of where we spend the most time, especially in the past few months, maybe even a year, what we’ve seen is that a lot of time is spent on the analysis, like taking the requirements, converting them into business requirements, but also from making sure that your dev team is working on those requirements, making- on marrying those two, right? So for us, a lot of time is spent on the [B arrow], we get a lot of new projects. And the last thing you want to do is you want to have all these projects that are in a backlog, you want to have these conversations with the business, you want to groom them as much as possible.

So a lot of- we’re seeing more and more time needed on the business analyst side and less time on the developer side because these are on our all ready to go. So we are changing our approach a little bit, we are trying to get more BAs versus just add the number of resources on the dev side because that is something that we can control. If there is a need for more dev resources, based on our current strategy, we can add and remove resources as and when needed.

Dayle Hall: 

So that’s an interesting concept. And I think if you asked 100 different leaders what they would describe as a business analyst, they would probably have a slightly different description. But I like what you’re talking about here, which is more effort on the planning and analysis before you go off and start creating a bunch of things. So talk to me a little bit about, what do you define as a business analyst, what do they do, what kind of skill set does that person bring into the organization to help you and your teams be more successful.

Leon Kallikkadan:

Sure. For me, a business analyst is someone who is well versed with the technology or what’s in the toolkit, but is not a developer. So that’s essentially someone who understands what your capabilities are. So it’s important that they have a full, deep understanding of what can be done, what cannot be done. It’s going to be someone who’s connected with the business, understands what the business is asking and is able to put some context behind it, because the last thing we want to do is we want to take a business out of business requirements and then hand it over to your developers and say, go and develop, because it’s not going to be done in a very, very efficient way. 

So we want someone who has that understanding of the business but also of the technology toolkit, and someone who has a very good understanding and hold on projects, like the bandwidth, right, what’s happening behind the scenes. Because our IT org is relatively small, so I try to maximize the use of every person that we have. So our BA is also the one who’s constantly talking to the business. So understanding what’s happening behind the scenes from a bandwidth, from a workload point of view, also helps us manage expectations, right? So for me, those three areas are the most important.

I am also trying to use what we’ve done for our automation across all aspects of our technology team. So people might not think of IT needing a business analyst, but I want my team to get to a place where every technology request that comes in goes through a business analyst. Because, like you said, the more you invest upfront, the better the outcome because there is no ambiguity, like what the business asked for, you have repeated 10 different ways to make sure that is accurate. And that’s where I want to get. So our solutions are quicker and more are to the point.

Dayle Hall:  

And just so I’m clear, do you have business analysts in your team, or do they sit outside of your organization?

Leon Kallikkadan:

It’s a mixture. So we do have a business analyst, but we also have- not technical business analysts, but our project team access our business analysts as well. So they do that at a high level. And because of our partnership with them and the time we’re investing, they have started to rally up their game as well. So we’ve got a good hybrid solution right now.

Dayle Hall: 

That’s really a good insight. Again, I hope some of the listeners who are listening to this thinking, maybe they’re going down this path, maybe they have some business analysts that they’re not utilizing, but there’s obviously more that they could do.

So talk to me a little bit now as we go into our third section, let’s talk about specific integration, automation for the business itself and kind of what you’re doing there. Talk to me a little bit about how important it is what you automate. And I think one of the things that we pre-discussed was talking about where the human and the intelligence of the individual that knows the organization, where do they play in the process of thinking about automation across the business.

Leon Kallikkadan:

Sure. Before I start answering, it’s important to share how I came to this conclusion. So when we started our team, the automation team, we were so excited about it, we launched a brand-new team, we’ve got all these fancy tools, and we were like, you know what, we can solve everyone’s problems, or we can automate all the processes. And that was the wrong thing to do. You can never automate 100%. Every process has a lot of automation capabilities, big and small. But what we learned is we can never automate 100%. There’s just so many complexities, the technology itself, the process itself, the exception sometimes gets in the way, and there can be an infinite number of exceptions.

So those are reasons why we chose to pivot to a more hybrid approach where, you know what, let us do where the task is repeatable, where you have a not unlimited, infinite exceptions, let us automate those, and let us try to see if we can get through that data. But we still want our resource whose time you’ve saved, we want that person to look at that, validate the data and almost analyze the outputs, make sure that kind of meets the mark, make sure that is within what they normally expect the range, identify exceptions or identify areas where there’s errors so that the person that was doing it now is now the analyst. And we had a process which would take a full day for one of our employees every week. And that was a long, tedious process.

So again, we thought we could just automate it 100%, and then we learned we couldn’t. So what used to take this person a seven to eight hours, now takes about two to three hours. But now what they’ve done is they are now sitting, waiting for the bot to send them the data. Once the bot is sending them, then they know how to apply business rules, which are outside, of which you cannot put into an automation script, so as to speak. And then they kind of work- once they’re ready, they will send an email to the bot and the bot kind of finishes the rest of the process. So the human in the loop kind of conversation is important for us because of the successes we are seeing. And also, we need our end users or the people that are running these tasks to be our check and balance. We want to make sure that our automations are accurate, but also in the event they’re not, that someone is able to say, you know what, hey, stop, something looks off.

Dayle Hall: 

Right, right. Yeah, that’s interesting. And that sounds like you’ve actually learned from some mistakes here because, again, you preface this response with, well, let me tell you why I’ve come to this conclusion. There’s just something- if someone is out there, and they’re thinking about, oh, we’re going to do the same thing, we’ve got so much we can automate, is there some example that you can share with us that’s not giving too much away of your internal processes, but something specific, you say, we went down this process and it fell apart? Is there anything that you can share with the audience?

Leon Kallikkadan:

Yeah. The instance I was talking about is report creation. And when I say report, we’re talking about the way we look at how someone is performing and so on and so forth, so some of these high-level reports. The biggest thing that we noticed was a lot of these knowledge users don’t have the knowledge for knowledge users in their head, right? It becomes very challenging for us to sometimes extract all of that information.

So along with this, there’s other ones where we just restarted expecting that we would do this, but then the end technology is not able to support us, right? We started this entire process, and then it kind of falls apart in the back end of it. So what we’ve done is, you know what, if you need to do this, let’s do this in multiple parts. If you want to extract it out, let the automation go and kick it off, extract it, get it to the state that you want. But before you upload it or whatever it is, make sure that, a, that other system is working. I know you can build in checks and balances over there, but try and get that in a way where it’s ready for upload and things like that. So there’s a few of those instances where we’ve learned kind of the hard way.

Dayle Hall:  

Yeah.Well, I think everyone has to go through that. So as we close this discussion, as I said, what I tend to find is people that contact us, when they listen to things like these podcasts, they’re looking for practical tips, practical pieces of advice. So if you think about- you said you can’t fully automate 100%, but you have a process in place, what should they be looking at to identify parts of the business that are more important to automate versus less important? How do you think about that for your organization?

Leon Kallikkadan:

Yeah. So when we started this, the way that we started to go after and identify opportunities was to go after low-hanging fruit. A low-hanging fruit, as always, the easiest ways to get some wins and build up momentum. So we started that way. And then we built our process. And I just want to say for anyone who’s starting this, the process builds over time, the process matures over time. It constantly changes, evolves. As you learn, as you mature, as you partner with the business, things will change, right? So it’s not what our process was on day one, which was very thin and not a heavy process, now looks very different. And we’ve co-opted that again- other teams have co-opted that.

Now we look at, hey, what is the value of an automation. We look at the amount of time that we spend or the estimate that will take us from point A to point B. We look at the value that this automation would give us like if- what is in our sweet spot is something that takes low effort, but has really high ROI, high value, right? And especially if you can put a dollar amount against it, the amount of dollars you can save or revenue you can generate, for me, that’s the sweet spot. But I understand that not all businesses will have those, so we look at those metrics, the amount of effort versus the amount of ROI, savings, whatever that is.

And we have a steering committee that we’ve instituted, that comprises our business leaders, my supervisor, and we bring that data, we bring the requirements and we say, you know what, these four requests came in, this is the amount of effort, this is the amount of benefit. Sometimes we even have the business user come on to a steering committee and speak, so they can make the case directly. And then as a steering committee, we decide what is deemed as high importance, and we execute, and we lay out our approach and say, we’ll start working on this sprint A or sprint 1, and then it’ll take X number of sprints to complete this.

So our process is more, we try to get the business as involved as possible. That’s not to say that there’s small projects we will not do, we want to do. But we also have to understand our role. If we try to automate everything for everyone, we are going to fail. So we just need to be selective about where we want to show the business the most value, and the business will decide. Like if it’s a revenue generating thing, that’s where we want the business revenue to increase. So it’s done more by using that approach.

Dayle Hall: 

When you said the steering committee that you have, that includes the functional leaders or the business leaders that go through that process. So they’re involved from day one of looking at that.

That’s really good advice. I’m pretty sure we could talk for another two or three hours. But I really liked what you’ve covered. We talked about your core teams. You make sure that they discuss all their projects and potentially, before any work begins, impacts on their organization. You also prioritize across those teams, which I think is important. So each team is not like, hey, where no one’s fighting for the most important thing for them, it’s really what- of the business, which I think is great. You talked about IT going to the user population, making sure you understand and you can engage more on their requirements, which I think is a great way to run the organization.

My favorite thing that you said, Leon, how can IT be an enabler of revenue, that’s an amazing mindset to have. And I think what you just talked about things like the steering committee and making sure that the business is bought into the priorities, and if it’s revenue first, I’m sure you’re going to get the right kind of support across the business.

The other part which I thought was really interesting was the business analyst piece, whether that’s within IT, or whether it’s in other parts of the business, but someone that is communicating, managing expectations of these projects with the business leaders, I haven’t seen that in a lot of organizations directly as that’s their role, so it’s really interesting that’s working for you. I’m sure some of the people around there that listen to the podcast could be going through this and thinking, hmm, we have been business analysts. I wonder why they’re not doing that for us.

But look, this is great. I think you’re doing an amazing job. I love how you think about automating the enterprise, which is obviously the mantra of this podcast. And Leon, thank you so much for sharing your thoughts today. It’s been an excellent episode.

Leon Kallikkadan:

Thank you. It’s been fun and it’s been a great conversation.

Dayle Hall: 

Right. For everyone out there, thank you for joining us today, and we’ll see you on the next episode of Automating the Enterprise with SnapLogic.