Cybersecurity at Western Digital: CIO Sesh Tirumala on People, Process, and Tech | Technovation 891

When I first joined a year ago, we were in the news and we had a cyber incident that impacted us. Obviously, one of the biggest learnings from that incident is that everyone typically focuses on technology, right? And I always break it into people, process, and technology. Unless you get all three legs of the stool in order, you're never safe.

Thank you, Peter. Super excited to be here. It's a great pleasure.

Western Digital is in the business of data storage solutions. It's all about high-capacity data storage and high-performance data storage. So essentially, we have a hard drive business and a solid-state drive business. We're pretty much in laptops, desktops, data centers. A lot of our large customers are cloud providers, whether it's Amazon, Google, Microsoft, Meta, etc. The company's been in existence for decades, and now with the buzz of generative AI, obviously we saw the first wave of a lot of the GPU growth, and from a data storage perspective, we see that as a second follow. So again, super excited in terms of the industry and where we are currently.

From my day-to-day responsibilities perspective, I have what is classic IT. I'm also responsible for the security organization, so the CISO reports to me. I'm also responsible for a lot of the data and analytics. And lastly, given that we are a global manufacturing company, a lot of the factory IT systems that manage our $12-14 billion business, I'm also responsible for those. So essentially, it's classic IT, data and analytics, security, and the factory systems.

Absolutely. When I first joined a year ago, a little more than a year ago, we were in the news and we had a cyber incident that impacted us. The team really did a phenomenal job in rallying behind and ensuring that we remediated the incident and got all our systems back up and running. Obviously, one of the biggest learnings from that incident is that everyone typically focuses on technology, and I always break it into people, process, and technology. Unless you get all three legs of the stool in order, you're never safe, or you never built enough guardrails in your ecosystem. We're a very complex manufacturing supply chain organization, so we work with external partners, logistics partners, customers. The parameter is there is no parameter, technically. So via the incident, we learned how to tighten up our change process systems, how to also look at our help desk systems because when somebody calls in for a password reset, how do you really validate who the actors are? Many a time you outsource your help desk function, and how do you ensure that even within your four walls and partners that you engage with are trained with best-in-class mechanisms of validation? Just like in your personal life, even though you have MFA and all validation, there's always a loophole. The team did a phenomenal job in taking those lessons learned in terms of our help desk processes, our technology, how do we also communicate with external customers and really remediate. We were fortunate that there was no impact from a revenue perspective or from our ability to ship product and continue our R&D, but it really shed light in terms of our people, process, technology. Since then, as a part of my own IT strategy, my number one priority is risk, compliance, and cybersecurity.

Absolutely. There's a cliché: culture eats strategy for breakfast. Different companies have different cultures, and from what I observed and what I've seen talking to a lot of my peers, one of the biggest things is how do you avoid stovepipes? In IT culturally, you're supporting a function. Let's say you're responsible for supporting sales, so you have a sales IT organization, or order processing, or financials IT. Obviously, you've got the functions in how you support the different stakeholders, but more importantly, you need to think of the connected tissue. One of the reasons I love being in IT is because you get to see the 360 view of the business. One of the things is, is the CIO more a business leader or a technology leader? I would say a combination of both, but it's got to be business first. You've got to understand the role of the business, where do we see growth opportunities, where do we see cost savings opportunities, how do you streamline and simplify your processes, how do you really delight your customers, your partners, your employees. That's the exciting part of being in IT. For me culturally, what I felt within the organization is everyone was working very hard within their individual functions and towers and measuring themselves, but when you flip it and come from an outside-in perspective, don't talk to me about Microsoft Teams and Slack and ABC, but what's the employee's experience in a meeting, in the way they collaborate, and how do you measure that? The biggest thing on culture was around flipping it on its head: don't be tech-centric, look at it from a process and outside-in perspective, and then bust the silos. The second thing is, it's a team sport. There's what's on the front of the jersey and what's on the back of the jersey. Never forget that. Respect the position that you play, but when you represent a stakeholder, you represent all of IT. You can't say, 'Hey, that's the network team's issue' or 'That's the infrastructure team's issue.' You've got to take accountability and represent it as a whole. Be hard internally to hold your peers accountable for improving service levels or operational level agreements in order to deliver a world-class experience. The biggest one is silo busting. The second thing is always respect the position you play, but you're playing for what's on the front of the jersey.

Absolutely. This is still a work in progress. We closely work with both corporate communications and with our people solutions teams. Is there a single team within a company that is responsible for employee experience? The answer is typically no. Therefore, I think IT has an opportunity to play 51% of the decision-making. The classic and traditional thinking is I have a team that's responsible for email, communication, collaboration. Then you work with facilities for your conference rooms in terms of video conferencing, audio conferencing, whiteboarding. Then you have, post-COVID, we still try to get people as many times in the week to come into the office, but it's about two to three days a week. What's that in-the-office collaboration experience? That's one set of capabilities. The second is, when I was getting interviewed for the job, what's my interviewing process? How seamless is the calendar setup, the meeting invite setup? Is it a one-click to join the meeting because you're already having butterflies in your stomach just before an interview, and you just want to make sure that the tech just works? Once you finish your interview, if you get an offer, what's your onboarding experience like? Once you onboard, how do you drive engagement? From I find you, to I recruit you, to I onboard you, to I make you productive, and I drive more and more of your engagement, and hopefully I don't have to ever leave, but in the event one does, people do for different reasons, then what's your offboarding experience? To me, the employee experience is really about that end-to-end from finding talent to growing them and nurturing them. The second thing is how do you also create personas? For example, we did this in my past company and here: day one, if a software engineer joins a company, can you make him or her fully productive on day one? That basically means that you've provisioned the systems, the tools, from writing code, you should be able to write code and deploy on day one. How do you have that mindset that it's not just about getting your PC or Mac with everything set up, but knowing that this is a software engineer and I'm going to provision a GitHub or a Jenkins ahead of time so you're productive on day one? Likewise, for a sales AE, access to Salesforce and access to a lot of the critical sales tools is all set up. Now all you're trying to do is get on with your onboarding experience and learning and being productive on the job. That's how I look at it in terms of employee experience: less about the tech, more about a day in the life and can you really make it efficient and frictionless?

One of the critical factors is also about taking stock of the skill set within your organization. It's super important to map out what are the current skills that you have, an inventory of all the key skills and competencies within the IT organization, and then look at where the puck's going in the industry. What are the futuristic skills that you need? You need to do a fit-gap analysis in terms of what you have and what skills are in demand and what you need. Then you need to really think about how do you bring in talent from early in career because you also want to create growth from a career perspective: early in career from university hires, university interns. The second thing is where do you need seasoned hires, people that bring in that skill set and know-how because you need to infuse technology or that business knowledge and capability within the organization. I would strongly encourage all CIOs to do a regular skill set inventory analysis between basic, proficient, and advanced throughout the entire organization, including leadership, and really be prepared in terms of the future requirements and needs. That's a super important success criteria within the organization.

It's always a balance between perform and transform. You've got to make sure that you never compromise the existing infrastructure, but at the same time, you can't swing to the other end where every change becomes a bureaucratic change that you just can't innovate because these days if you don't innovate, you're left behind. It goes back to how do you create an IT engagement model and the culture of leaning in. It's a team sport. Rather than treat the CISO in terms of, typically people think, 'Well, as soon as you say a security organization, it takes too long or there's not enough resources.' To me, it's really having clarity on, as we engage with the business, to the best we can get a sense for the key priorities, the roadmaps, the investments. I think it's super important so that you can apply your scarce resources against the highest order bit. The second thing is also being very close to your procurement organization because a lot of the software purchases happen through, and many times even IT is not aware, and it goes straight to the procurement team. Having a close interlock with your procurement team and teaching them and training them so that they push back and are able to rope in and bring the CIO and the CISO into the conversation when certain flags and conditions come up during the review process. Those are two critical things. Then continuing to teach the organization because, let's take Sarbanes-Oxley as an example. Risk and compliance, SOX is a big compliance aspect. It's not a one-time, done-and-dusted effort. It's got to be a part of your day-to-day performance and SLAs and management with all changes. Sitting with the finance organization, sitting with a tax organization, making sure that all the controls are well tested, more importantly, is it well documented? The second thing is, do you have the right practices to ensure auditability and compliance? Then when you do with an external auditor like PwC, are you able to demonstrate both as a business and IT organization the strict adherence to all the SOX controls? It's funny because when you have a large team in India and Asia, many a time early in career people also learn through production support and SOX compliance and testing. I was in an all-hands once and I was talking to people who are early in their career. I asked this individual, 'What do you do?' 'Well, I'm just doing testing of these controls and validation.' Then I mentioned, in my own hand, that if we fail the SOX, significant deficiencies and demonstrate that we have material weaknesses, guess what? It means that a lot of the C-suite goes to jail, including the CIO. Failing a SOX audit means jail. That light bulb was, 'Oh my God, this is why it's important to have fiduciary controls. This is what it means to be a publicly traded company. This is why it's important.' It's important for people at the lower levels to understand. Otherwise, when you're just testing a control, it may sound a little mundane, but how do you translate it to the work that you're doing on a day-to-day basis is so critical that it can put your company at risk from an SEC reporting, financial fiduciary requirements perspective. For publicly traded companies, these are something that you never compromise. Making that a part of your culture and your DNA is super important. Likewise with cyber too. Our past learnings have been that we tend to go to the board meetings and you have these NIST frameworks and you have these maturity colors that you basically say where you have green. I always call it the watermelon effect: it's green on the outside and as soon as you slice it, it's red on the inside. How do you ensure that you really are being practical about the NIST framework and you're able to call out the risks? To the best you can, you need to quantify the risk. It's about people, process, technology. It's also about even simple things like these days all the phishing emails you get, and how do you train the organization when to click and not click? All those are super important. Just doing a one-time tabletop exercise is not enough. It's got to be a regular sport that you do frequently. The last thing is, when you have an incident and when the going gets rough, you'll truly get to know who's a partner and who's a vendor. We clearly learned who was truly willing to go above and beyond and demonstrate partnership versus some that were just vendors. Then you need to know what you have to do to figure out your next step from that experience.

Everybody wants to work on cool capabilities. I call it perform and transform. Perform is like water, gas, electricity. You expect it to be always on, and when things are not always on, it creates big issues. From an IT perspective, operational excellence basically means that all our services are up and running: email is up, collaboration is up, all the mission-critical ones, the ability to message, meet, collaborate, place orders, your website is up, you can book revenue, you can ship product. I call these always-on services, and they better have three nines or four nines in terms of availability. It's a cost versus investment balance, but to me, operational excellence is always-on services, no compromises. Obviously, in the software world, stuff happens. It's important that when things happen, it's the attitude with which we respond, not a finger-pointing game on a bridge. What is the meantime to restoration when an incident happens? This was classic with my previous company, PagerDuty. The whole premise was around how do we minimize downtime. Likewise, we implemented PagerDuty when I first came on board. The thinking of operational excellence is measure your always-on services, and anytime there's an issue or an outage, let's learn from it. Again, people, process, technology. Most of the times, you have to measure yourself in how good you are with changes. Many incidents actually happen due to changes. How do you minimize change-related incidents? When things happen or go south, have a robust rollback plan or a fallback plan, communicate early, and escalate early. Asking for help is not a sign of weakness. We recently had an issue with one of our big software providers, and the team did not even know who to call on the partner side. Knowing who to call, how to escalate even with your big software providers and partners, is super important. All that I call operational excellence, and you measure in terms of uptime, outages, change-related incidents, meantime to resolution. On the engineering excellence side, it's about having the right process and tooling to deploy software. We still have some work to do to fully embrace agile. Agile is not about producing crap faster, but you have to have the right due diligence across the board. Once your requirements and outcomes are well understood, how do you accelerate with the business and bring the business along on this journey? Engineering excellence is all about: do I have source code automation? Can I do unit testing and dev testing and integration testing at scale? Do I automate a lot of things both from a cyber and security perspective and from a code-based perspective? Can all my ML and data engineering and pipeline engineering be digitized and automated? Are we really leveraging the cloud-first mindset rather than build everything in your data center or in a colo? A lot of these principles go into thinking about security first rather than an afterthought, even during your code review process. Those are the two pillars: operationally excellent and engineering excellence, and bring in the software-defined paradigm even from an infrastructure perspective. Especially with logging and monitoring, but what is truly observability? In the industry, the word observability is super important. Classic IT, it's a network issue or a data center issue or a data issue, but how do you, because the users don't care where the issue is? 'I can't book an order' or 'I can't engage with you on your website.' End users should never care about what's broken, but it's our job in IT to ensure that we are accountable for that end-to-end experience.

I spent a long career at Cisco and led a lot of transformation, great journeys across the business. Having seen the company grow from when I joined, they were like $4 billion, and when I left, we were about $51 billion in Cisco. Going through the sales go-to-market growth, the e-commerce growth, the shift towards new business models like software as a subscription also for on-premise networking gear, data center gear as a subscription. Thinking through that whole business model shift, building systems for scale with high operational excellence metrics that I mentioned was a huge learning from a Cisco perspective. As a part of my next career growth and movement, I joined Anaplan and PagerDuty. One of the biggest things when you join companies that are much smaller and you have a smaller footprint even within an IT organization is that in a large company, you take things for granted because your budgets are fairly large, you have larger teams at your disposal. When you're in a smaller company, everyone's got to own top line and bottom line. In the SaaS companies, the rule of 40 was super important between your profitability and top line versus your expense and OpEx. How do you really thrive towards the rule of 40? Many companies were still not profitable despite good growth, which means it's all about the bottom line and driving more efficiency and more automation, doing more with less. The biggest learning there was with every hiring, where you digitize, where you automate, and really look for partnership with the CFO on what are the levers towards accomplishing the rule of 40, and really trying to do within IT what can we do. That was a big learning and takeaway, and really being a lean and mean organization. The second thing was, many a time you're selling to fellow practitioners, CIOs, CTOs, CISOs. How do you also help influence the product in terms of the storyboard, the pitch deck, what features and functionalities are important, how do you unlock relationships and really provide the practitioner's view back into the product? What drew me back to a larger organization was partially a personal reason, but at the same time, I wanted to get back into a global manufacturing footprint from a more personal career perspective. The complexities of a large organization, having been in small teams where you have to really be conscious about your investments, helps me bring that same value for money because at the end of the day, we got to treat all of this as your own personal money and really think about that value for money conversation. How do you measure ROI? How do you ensure that the costs and expenses are in line? One of the biggest things we always get dinged on in IT is 'takes too long, costs too much.' That's just the tagline no matter where you are. How do you continue to have a storyboard with the right metrics to show exactly what your costs are? What's your annual budget? Let me break it down between what's fixed and what's non-fixed. Having that narrative with your CFO and the C-suite is super important. One of the beautiful things of being in IT is you have no dog in the fight. Many a time, being in the middle of breaking logjams between a CFO or a CRO or a COO because you just lay out the facts and go, 'Well, here's what's being asked of me, and here's the scarce resources, and the business case we've implemented it, but we don't see us accomplishing the business case. So do we continue to feed the beast or do we cut bait?' I call it courageous decision-making and the ability to influence and bring via a steering committee the right leaders at the table to have the uncomfortable conversations. I think that's an expectation of a CIO. That's been a good growing opportunity. Early on, I've had my own scars where you say some things and you don't realize the political landscape, but you've got to be politically savvy and you've got to tear it up and grease the skids a little bit before you're able to talk about what the outcomes are.

I'm trying to bucket things between perform and transform. I still have a few things or many things to accomplish on the perform bucket, which is all about cloud-first, asset-light, beef up our risk compliance posture, employee experience as a pet peeve. How do we continue to digitize and look for value for money? Are we getting the value for money from all of our major platforms that we are invested in? All these are multi-year subscription deals. Are we really getting the value for money? Are we engaging with the partners on a regular basis, pushing for features and functionality? A big chunk of it is in the perform category: employee experience, customer experience improvements, your risk compliance and cyber posture, and really being asset-light. On the transform side, potentially a business model shift in terms of as-a-service. That is one. The second thing is data, data, and analytics. I still think that a lot of our metrics and capabilities are rearview-looking. It's not unique to us, but it's about an industry too. Don't admire what happened in the last quarter. Still, if you look at many companies culturally, you're running QBRs. You're sitting in Q4 and you're running a Q3 QBR, which is a rearview-looking to begin with. We tend to drain slides and talk about 45 minutes in an hour meeting about what happened last quarter rather than, 'Hey, here's what I'm going to predict is going to happen this quarter and next quarter, and here are the adjustments I need to make, and here's forward-looking.' On the analytics front, we need to be forward-looking. We talk a lot about GenAI and the buzz. I think it all goes back to having a robust data model. How do you take opportunity data from Salesforce, bookings data from an ERP, to an install-based data in your install-based system, your entitlement data, and really connecting it from the lens of a customer? Who have you sold to, sold through? Because in an ecosystem, many times you're not selling directly to end customers; you're selling through a channel. It's super important to understand your routes to market, your go-to-market motions, and really know who your customer truly is, and really focus on the right data quality and data completeness problem. In a way, it's back to basics. Once your data model is robust and strong and you have the right technology, whether it's a lake house or a data warehouse in the cloud, all those are given table stakes, and you have enough ample technology choices to pick and choose from. Then comes, in the future, gone are the days where somebody's going to log into a Tableau or a Power BI and run a report. You're going to have a prompt and you're going to say, 'Who are my top three customers?' or 'Which product of mine is generating more than $10 million in revenue?' or 'Who's my top sales rep?' All these are going to be prompt-based questions to find information. The second thing could be actions: 'I want to take a Monday off in July, and let me know what's the best time to take it.' You get a prompt back, and the system creates a record in Workday, and you get your time-off request approved. That becomes an action-based. Long story short, it's about prepping the data models and then embracing the right LLMs and the right technology architectures to enable truly how do we do generative AI based on the different departmental use cases: what's relevant for sales, what's relevant for engineering, what's relevant for employees, what's relevant for manufacturing. The other area that's super important for us is IT and OT: IT being Information Technology, OT being Operational Technology. We have a lot of factories, and these are world-class factories in the Far East. In these factories, how do you have the concept of a digital twin? How do we use imaging, text, videos to predict quality problems or reliability problems, and really figure out from your production line and your manufacturing line how do you demonstrate the best operational technology where the yields are super high, failure rate is super low, and your production lines are at full capacity with very minimal defects? We call it the factories of the future: fully digitized, fully automated MES systems. Those are super important. In OT, we're also looking at technologies from a security and facilities perspective. If there's a fire, do we have enough sensors to detect there's an issue because you can't physically have people deployed everywhere? How do you respond in terms of a crisis in OT technology and large campuses and large factories? Those are just a few things we're considering across the realm. Some of it is back to basics, and some of it is more futuristic and forward-looking.

There's this book called 'Working Backwards.' I think it's written by some people from Amazon. One of the things in it is always about how do you tell the story with the end in mind and then you work your plan backwards. Many times in IT, when we communicate, we're talking about widgets and technology and tools and less about the story and the narrative. If you want to think about a product mindset, you need to think about the finished product and then work your milestones and plans backwards. The second thing is even in your PowerPoints and the ability to create the storyboard and narrative, what's the punchline, and how do you use as few slides as possible to really talk with a bias towards action? I think that's a good read in general to talk about a finished product in mind and then work your way backwards and iron out all the kinks. It's like writing a press release. If something's going to go out, let's say you have a big ERP release in a year from now, how do you write the press release as though you're 12 months from now and answer all the key questions, and then work your plan backwards?

Thank you again, and likewise, Peter. Thank you for the opportunity.