Adopting enterprise risk management to conserve capital with Dipanjan Choudhury of ValueMomentum

Ledge: Dipanjan, welcome. It’s good to have you.

Dipanjan: Yeah, good to see you, Ledge. I’m happy to be here.

Ledge: Can you tell our listeners a two or three minute version, your history, your work and what you’re doing these days?

Dipanjan: Yeah, sure. So, I’ve been all it’s like 18 years now. Always worked in the software industry. More on the technical side; development, design, account management stuff.

Now I’m more into a pre-sales role here. I work for a product development company called CAST, which is looking into the software risks of applications. We also look into the areas where the customers are doing technical due diligence, or they’re migrating to cloud. What sorts of things they require. What are the strategies they will require?

From the risk perspective, will look into areas like performance risk or security risk of the application, how those can impact in the production environment. So those are the areas we look into. I’m in the technical side, so I’ll talk to the customers, explain to them what our products do, what the value they get out of our products. Also, we work in long-term, implement the product, walk with them in their journey.

Ledge: What kinds of models are there for figuring out risk? I imagine you do a lot of thinking about this.

I don’t get clients in the new green field type of products thinking a whole lot about the risks, other than, I don’t want it to cost too much. So, what are some of the risk profiles that you think about from your standpoint?

Dipanjan: Well, and that’s the irony, right? If you think the modern applications, they are getting complex and complex, much more complex than anyone can think of. You have the list of APAs they are calling each other. You have the microservices. You have connectivity to the external system. You have connectivity to the legacy applications. All sorts of things.

There are so many unknowns in the current software paradigm, specifically in the enterprise application field. Not thinking of risk is really not the correct way to move ahead and progress, and I think you are not doing proper service to your customers if you’re not thinking of the risk of the applications. So, I think that is definitely there.

How it varies and where it varies depends on different scenarios. One of the things that the legacy side of the applications, which are pretty old, which sometimes are very difficult to map into the current business requirements when you try to scale them. We’re seeing lot of application modernization. When there’s the testing of application modernization is when you are trying to scale up the software. Or when you want to refactor it altogether, there are so many risks. Because the business logic that are embedded in different areas, people are just using as it is. They’re working fine. No one even touched it.

Those are the areas you definitely need to look into from a legacy perspective as we’re doing a modernization, or even if you’re trying to integrate to them what other functionalities are there which may not have been known to you. That’s one of the areas CAST is looking into.

The other thing is, of course, in the modern applications, we’re more into DevOps environment right now. We’re in the DevOps and CI/CD environment. We’re having a sprint running every two weeks to three weeks.

In this type of scenario, the risk is a bit different because many of the times that things are going into production environment with proper testing. Sometimes, people are just trying to phish out new product versions every two weeks, every four weeks, because that’s the business.

I think it’s now more relevant to have the risk portfolio for applications get assessed in a proper way. How do you fix? What do you fix? What are the low-hanging fruits, or we have to go very deep into that part? Overall perspective risk is always the one you should look in.

Software, to be honest, is not very different in other industries, per se. So, the quality control, the quality management, I think it should be embedded as part of your whole process system.

Ledge: Right now I’m seeing a trend, when I talk to CTOs, that both QA and security seem to be moving – what they say moving left in the software development process. They’re becoming ops functions, and even all the way back to product functions.

Are you seeing that at the enterprise level as well?

Dipanjan: Absolutely. I think that’s a very good point that you touched. Shift left is really the ones that we are talking about a lot in CAST also, right now. They should be moved right after the dev itself. Personally, that’s what my belief is.

Many of the CTOs and CIOs we’ve been speaking with are the senior architects. They’re also trying to bring the risk part, specifically the security part, right left. So it doesn’t go… It’s difficult to control but doesn’t go beyond the staging environment.

That’s what you always want to do, because the cost of fixing those risks as you move left gets lesser and lesser, and less impactful. As you move on the right-hand side, it can blow up.

Ledge: We’re in the business of very senior, remote, distributed engineering teams and engineers, software engineers, architects, DevOps. I wonder, what’s the appetite and what are the changes around the evolving in remote workforce?

We see some legacy organizations that are not bought into that yet, that they can have remote and distributed workforces. Others are doing really well in that regard. It’s difficult to look at the macro variables and not think that everything will be this way.

Are you guys helping organizations think differently about that, to make use of the remote workforce?

Dipanjan: That’s really a challenging part. I have seen organizations who have done remote, went remote. They have figured out there are a lot of flexibility. Specifically, from the developers and the resources perspective, who can do in their own time.

But again, there is always the concern of the security aspects, I will say, per se, which is really the one which is very challenging. Again, I have seen that they are coming back and saying, “No, you cannot go and do it remote. There is a lot of data. The customers’ data is with us. I may not allow you to do remote work.” Or even the BYOD, the bring your own device, you’re doing from the mobile or you’re doing from the tablet, and maybe from a personal one. Customers are not allowing that.

I think this is much more relevant in areas where you have a huge customer data dependency, specifically in financial one. I would say in pharmaceuticals also, you have a lot of rules and regulations, what happens. As you have seen this year, you have GDPR regulation coming into Europe. These are making it more strict and more strict.

It’s getting a bit difficult for many of the companies to allow the customers to work from remote. It really depends on what functionality this particular resource is working on.

Ledge: Sure. And we, certainly as an industry, will have to address that even in the most sensitive data areas because it’s becoming, or at least seems to be now, a seller’s market. The employee gets to drive what they want. You can’t get access to the best talent, unless you provide the ability to work in the way that they want to.

Dipanjan: Well, the employees, I would say we have to keep faith on them also. They are also sensible, what can be done, what cannot be done. You cannot always get the best or the most flexible options if you’re working in a great environment which is providing the options to do good, cool things. But they may have restrictions of whatever reasons, whatever policy they have

So difficult things. You are saying a lot of options for employees, a lot of options for employers, I think we’ll reach some equilibrium someday.

Ledge: There’s a model that fits for everybody. Right.

The last question I like to ask everybody, different views on this. Obviously, we’re in the business of evaluating and staffing and finding the best software engineers. So independent freelancers who have senior careers and are really just A plus players that we want to place with our clients.

We have a process for doing that that we’re constantly evolving, and I like to ask all of our guests, what are your heuristics for what make the best of the best software engineers? How do you know them when you see them, and how do you evaluate them?

Dipanjan: One of the options that I take into the recruitment process… Recruitment is always a thing that you are never sure of what you’re recruiting, the people, who is coming in. He may be a great engineer but he may not be the fit for your organization. That’s always a challenge.

Even when I have gone and I have changed my jobs, that was always a thing. When I go and change, okay, it looks great but you have those initial rules. That, well, I’m going to… That I don’t whether I’ll fit to their culture. Whether I’ll be able to do or not do what I want to do?

Those are areas always there. But I think one of the best ways to look into it is, instead of having curated questions, talk to the folks and figure out what they have done over the years. I think that’s the best way to start. What they have done, what they would like to do. And the third part is, of course when you have a specific requirement, how much they are mapping to that.

One of the things I think is the better approach, and I spoke to many of the recruiters also on this part, is when you figure out who’s the best resource, it’s not necessarily the one who exactly knows what you want to do right now, but who has a lot of flexibility to learn new things.

And if you see in the current world, every technology is changing, is evolving. So, you need players who are very flexible, who can change according to the business requirement, because that’s what is putting the flow to the technology. Who can change it, who are adaptable and who are culturally amiable to your organization.

Those are the things that you really need to look into. Without that, it’s difficult to have someone work for you for a long time.

The second part is, of course, the technical aspects. I you’re looking for someone in the cloud, you must really want to have someone with the cloud architect level, especially in the senior level, in the representative level.

If you’re looking for someone in the developer, like you are creating your own cloud practice and you are looking for a junior developer maybe just out of college, you may not focus too much on that. You must really want to work how his mentality is. Whether he wants to work for us, whether he was flexible. So, different levels it varies but what is very important is having the culture amiability. I will definitely say that.

Ledge: Yeah. And you touched on, hey, you want to know if they have, on the technical side, senior abilities in skill X. I think the smart organizations are able to take that leap and really define what is the measure of a senior ability in skill X. That takes a lot of work, that on the recruiting side, just knowing what you are looking for. It’s not enough to say ‘cloud architect – senior’, because that’s just a thing that anybody could write down.

Dipanjan: Yeah, anybody can.

Ledge: You need to know how to evaluate that, and that skill is critically important.

Not just search LinkedIn for the right job title.

Dipanjan: Makes sense, yeah?

Ledge: Dipanjan, it’s good to have you on. I really appreciate your insights.

Dipanjan: Yeah, thanks for that. And some of the points that you are also bringing in. I know you’re from the recruitment one and you were talking to lot of architects and the developers. I really see the pain points here and the challenges. The technology stack is really getting diversified, not in the good old days. So, yeah, it’s getting more and more challenging. I agree with you.