Our conversation today covers investment planning for 2023 for CIOs and CTOs. Our guest is Arthur Hu, Global Chief Information Officer and CTO of the Solutions and Services Group at Lenovo. As the CIO, it's really about helping power Lenovo, which is a $70 billion powerhouse today. We're in the Fortune Global 200. As CIO, the role is really about how to make sure that the $70 billion business runs 24/7/365, as well as driving the transformation. We'll talk more about that later. On the CTO side, it's really a little bit different in the sense that it is very focused on our customers and how we take the best of what Lenovo has to offer and bring them to the customers as services and solutions. The CTO role is about planning and building that technology future
and about the portfolio for the business group. What are your objectives as you think about 2023? As the CIO, it's really about helping the company continue to be agile in the face of uncertainty (to be more specific). Obviously, the business needs to continue to run to keep the lights on. It has to go flawlessly and seamlessly. At the same time, we find ourselves with a couple of other factors. One is the macroeconomic environment, which is injecting a lot of
uncertainty, which means the goal is to help the company navigate that. At the same time, as a strategic objective, we're continuing our transformation from a hardware-based company into one that's hardware plus services and solutions-led. That's really like building an entirely new company. The CIO role is really helping how we build the processes, the technology, the tools, and the systems to enable that growth and transformation. On the CTO side, the objectives are really
about how we envision the next generation set of services and solutions we want to bring to our customers. For example, around digital workspace, around immersive reality, around the right managed IT services to deliver outcomes for IT leaders around the world. Now, what ties those together is that it's really all about using technology in order to power, whether it's powering Lenovo, or it's powering our customers as well. That's the thread that ties it together, which is, if we think about it, Lenovo is (from an IT perspective) my main customer. At the same time, our solution and services group (SSG, as I'll refer to it to save us some time upcoming) is trying to serve people similar to myself. We want to build a platform that ties together that says, "Let's take the best of what Lenovo builds today and use it not only for ourselves but to help our customers achieve their objectives."
As you think about the investment decisions that you're making, what is the criteria? What are the evaluation points that you go through? It's a complex process, especially with these dual roles. Let me take you through some of the frameworks to think about this. The first one is, of course, tying with the business strategy and the business value because, ultimately, whatever you're investing in, you want to be sure that, whether the time horizon is one year or three years, there's a return that's going to be tangible and recognizable to the business in that timeframe. That's the first part, and I would say that's one of the key pillars. The second piece is really going to be around our ability to execute. As you sort through, there's a very important part of the prioritization, which is how executable are these things because you want to make sure, with transformation, there's going to be different levels of maturity and readiness to receive or to implement and land what it is you're doing with the business. As we
go through the process, we're also going to take a sharp eye on which parts of the business look like they are more enthusiastic, they're more willing to put in the work with us to make that happen. We'll also consider track record. This is important as part of the closed loop. I think, as you and I have seen, one of the key things around our environments, especially with large enterprises, is complexity. It's very hard to say this one thing led to the outcome. If we did a project, for example, there are many other variables that could lead to an outcome. Let's say we're targeting to improve customer conversion rates. But
because there are so many variables in that, it's very difficult to attribute. When we think about the business cases, it's really important also to consider how well have we executed with these teams in the past because we want to and will preferentially weight teams that have a track record of working well with us, and our ability to deliver. Everything looks good on paper. But when the rubber hits the road, when the outcomes are done, and when you look at a track record over time, you can create a much better picture.
I think it's a combination of what are the things that deliver value to the business, what are the things that we're able to land, and then, finally, from a technology perspective, what are the things that we need to do to make sure we keep the architecture modern and ready for the future because I think, as part of maintaining the architecture freshness, we'll say, for the future, you never want to let the technology debt get too high. And so, it's a combination of the strategy, the value, the executability, as well as the technology aspects. What I find particularly interesting is how this planning process seems deeply rooted in both the technology side, but it seems equally so in the human side as well. I think a lot of it also goes back into the planning in terms of how do I ideas make their way through the organization because all great projects and all projects that really deliver outsized value, especially relative to the baseline and the expectation, are rooted in a strong partnership between the technology and the business teams. On the people side, it's really
important, I've found, that from the inception, even when you're brainstorming about a project, the best projects that I've seen will tend to be ones that were co-conceived, co-brainstormed, and co-sponsored soup to nuts with a strong partner in the business team. That doesn't happen overnight. A lot of my time, whether it's in the CIO role or the CTO role, it's been an integral part to make sure that you're investing the time not just in the technology because I think it's table stakes. The company expects you to be fluent and to be deep in the key technologies, and to make that accessible to the company in terms of what it makes possible.
What really makes the technology sing is its deployment, usage, and uptake. That part, I think, the human side comes into play so important because when you have the partnerships that you've built over time and you have the trust, the trust ultimately is actually what allows you to really gain speed and move quickly. I think, in addition to the general notion of business readiness, are they ready to accept the change, are they willing to embrace the change, roll up their sleeves, and do the hard work of knowledge transfer and organizational change management? The sponsorship and the trust are huge accelerators when you can get them right as well. As you're thinking about technology and ensuring
that you don't have the overhang of technical debt, at the same time you're also thinking about the uptake into the organization and how the organization can absorb that technology. Is that an accurate way of saying it? It is, and I think the challenge there is really helping the business have the right mindset for viewing it. Let me give you an example. If you think about programs, the most visible things are the functionality. If you think about
any RFP or anything where you're evaluating, the first thing on the list is what will it do: one, two, three, four, five. And that's fair. It deserves its place in the evaluation. What's important for the business to recognize, though, is then they say, "Well, if we need to beyond this." It's like the iceberg, maybe to use another example. That's part of keeping that healthy as part of making sure it integrates well, as part of making sure that it's properly architected, as part of making sure that the technology stack is going to be up to date.
There's additional work to be done, and so the technology debt – sorry, making sure the stack stays modern is helping the business understand the whole picture, but in terms they understand. If you say, "Hey, I'm going to give you the functionality and I have to do a bunch of back office work," it's a little harder for them to understand. If we take an example recently where we talked to the business about why the project cost was higher than they would have expected to, quote-unquote, "just deliver the functionality," if you say, "Well, I've got to do a bunch of" – insert technical jargon there – they don't understand and process. Instead, we've had to reframe the discussion to say, "If we don't invest in this, it's actually going to impact, ultimately, your agility. You may get this live now, but in 6 months, in 12 months, your ability to release quickly will be slower. Your ability to upgrade and get the latest platform features will be slower."
Then they say, "Oh... Okay." And so, that's been one of the tactics that we've had to use because I definitely remember – myself included, and my teams – we would spend significant time trying to tell them why we needed. Tech debt is kind of a hard concept, and so we've even stopped using so much tech debt but started talking to the business and meeting them where they are, so using terms such as, "Hey, look. It's going to be harder for you to upgrade." Okay, they understand that. "It's going to be slower to release because we have to do extra regression testing." Okay, they get that.
If you say, "Well, look. Do you want to pay it now or pay it later?" paying it now means you don't have to pay it later, and it's a better philosophy. You can illustrate why that is. Then they're much more receptive. I think that's the bridge that we've tried to build between the business and also technology debt in a way that's accessible. We have an interesting question on Twitter. This is from Wayne Anderson who says, "With an uncertain market, maybe a year or two of global flat growth, does the budgeting and planning approach of the CIO needs to fundamentally change?" The planning fundamentals and approach don't need to change, but certainly, you need to weight factors differently. What I mean by that is, in any healthy planning cycle,
you're going to be thinking about where you need to invest, where you need to optimize, where you need to stop or reduce, potentially. When times are good, you're going to overweight on the invest for growth, and maybe more on optimization, less on the stop or reduce. With uncertainty, then I think IT professionals around the world are going to be faced with do more with less, inevitably. The picture really evolves around, well, how do we save? And, if you want to invest, save to invest. The aspects about
what we want to stop or how we rebalance, I think, get weighted significantly higher. If you set up your budget planning the way I have, you don't have to say, "Oh, throw everything out. Let's start over," but it's simply a matter of giving the factors different weight in the portfolio that you're looking at. I think that's the key, which is not to do a 180. I think, again, it's education with the business because IT is longer-term. It's very hard. For example, we have many projects, and I think many in the audience who do this professionally are in the same boat. We have multiyear transformations.
That doesn't make sense to say, "Stop." For example, at Lenovo, we're not going to become a solution and services-led company. No, we are. That's going to continue to be the aspiration, and we have significant capital expenditures aligned to achieve that. We're going to continue those.
The question is then how do we rebalance? How do we take a really hard look at things that we are already doing today so that we can continue to fund the absolute strategic imperatives? Please subscribe to our newsletter and hit the subscribe button to subscribe to our YouTube channel. You have a trajectory, and that trajectory has a variety of different components. But it's a longer-term trajectory. And so, therefore, you're making adjustments as you go but not significant changes, necessarily, due to a year or two of a change in the economic climate. Again, is that a correct way of paraphrasing what you just--? That's exactly right. I think the way I think about it, which is our strategic direction
and the strategy of the company have not changed. But our tactics may change. We may go a little faster here. We may zig where we were going to zag. We're going to make small adjustments, but we're still going to be pointed in that broad direction. Now the other piece that's extremely important, as I'm also going through this real-time as we try to navigate the uncertainty, is that this needs to be an iterative game. Similar to how we
run sprints and we're going to continuously test for feedback, I think planning is the same way. Now Lenovo is a public company, and so we report out quarterly. The way to navigate that, though, is within the construct of having budgets because if you tell your CFO at a public company, "Please, I don't have annual targets. I don't have quarterly targets," that doesn't fly.
But within that construct, I think there are tactics you can take to hold some contingency and to work with the CFO and the organization so that you have the ability to maneuver. And you can create that for yourself. If you say, "I'm going to take some from over here and rebalance so that I can do more that's strategic," that's going to be important.
The iterative part also is don't assume it's a one-off, which is you get a target and you have to say yes or no. What we're finding is because there's so much complexity and because there are a lot of tradeoffs to be made, it's an active conversation over time. When we do it at Lenovo, it's not about, "Yes or no, is this the target?" It's, "Well, let's make sure everyone fully understands. We can hit any target that the company gives us, but does the company fully understand the implications of doing so? For example, if we say, "Hey, we will need to slow down these strategic releases by 25%," and, for example, one of our major releases is around improving our everything as a service platform. If we wanted to slow that down by 25% and the business says, "No,
we want to prioritize that," and they say, "Well, maybe that part of the budget we don't touch." It's important to recognize, to create the space for dialog because the more that the business understands what it is, the more it becomes a collaborative exercise. Anything in my book, Michael, that draws the business into the discussion about what are the real tradeoffs here and what's really valuable I think is a win because you want people talking about how the technology lands and how it's applied and if they're going to sign up with you. This is how you align your investment strategy with what the business ultimately needs to ensure that you're meeting the business goals. Yes, exactly. Our governance
actually reinforces that. Whenever we have a business case, I think there are two things that I want to call out. One is that when we sign on the dotted line to say commit, it's always a multi-line. There's a business sponsor, and there's a technology sponsor. There are people on both sides who are committed to make it work. The second part is what I talk about, which is we need to lengthen the time horizon.
These are never one-off interactions, and so you want to make sure that the people you're signing up for have credibly worked with you and delivered in the past. I think those two elements are very powerful because, at Lenovo, we're actually pivoted to strengthen the weight and to strengthen the voice of the business in technology decisions because, for us, we found it had a very powerful ownership effect. When it was myself, for example, I sit on our executive committee. I could see the marked difference when I would get up by myself to make a pitch for why our latest project was delivering value. Then we ran kind of an A/B test. In the next one I said, "Well, what if we co-present?" Variant one was when we would co-present, myself and the business president or the sponsor (about the impact of technology). That was way better.
The best part was actually when I just shut up, and I actually wouldn't speak about it. It would be the business achieved something really remarkable that they felt was noteworthy of discussion or needed to be shared, and technology was a part of that. That actually got the best reception over time because then the rest of the executive committee, the rest of the company felt we were really committed. I think it's worthwhile for everyone to
consider running that type of experiment. What's right for you in your context in terms of how to get the business buy-in? Michael, I think it's very important. Those are just some of the tactics to consider in terms of getting that business alignment and follow-through. Let me ask you this. Going forward, as you look into 2023, are there unique opportunities relating to technology or relating to opportunities for CIOs and CTOs? The first one that comes to mind is some insight that kind of shook me a little bit in a positive way to think differently when I took on the CTO role for our solution and services group. It was this: In the CIO role, as an expense or as
a cost center, you're constantly evaluated on the efficiency, and are you underrunning your budget or can you save relative to the budget? If you spend more than your budget, then you get a nice call from the finance organization asking why and will you please go back to the budget. When I became the CTO, there was a budget, and we were not spending as much money as was forecast. And so, I expected to get a congratulatory call, "Great job! Thank you for underrunning the budget." Instead, I got a call, and they said, "What's wrong with you? Why can't you spend the R&D budget?" The ah-ha moment for me that was so fascinating (to think about my own mindset and trying to figure out, well, how do CIO and CTO roles, and what's different and not) was it was a mindset because the company viewed IT as an enabler, yes, but ultimately, because of the accounting, it goes under the SG&A line on your P&L. R&D is an expense that's expected to generate growth. And so, when the company looks at the R&D (under my CTO management) and says, "Oh, we're not hitting the targets," they see that as, "Oh, we're not building the future."
I think, whether you're a CIO or CTO, one of the key mindset shifts you can think about is, "Well, what is the value? How do you think about this as creating growth to the company?" because regardless of the accounting and where it falls on the P&L, if you can sign up and convince a business leader that the spend – because it's all technology, right? These are in some sense accounting distinctions. But ultimately, we're building and using technology and software to create capabilities that we think will empower our customers. If you can get the business to sign up for that in the mindset that that's going to generate near-term, medium-term, or long-term benefits in growth for the company, that's a whole new ballgame. I think that's been a powerful mindset shift for me,
and it took this kind of joint role to get me out of, "Well, let me just hit the budget." It's really, "How do we create value?" Then it's true. If you find that with the business, spending more is fine because you're going to ultimately make more, that's a much easier discussion than, "Well, please just stay within the budget because that's how we view you."
I think it's a little bit of a breakout mindset that's worth considering, especially, Michael, as we're starting the new year. New beginnings and all, I think it's one of my resolutions to try and carry that forward and to extend that discussion and mindset with my team. What can CIOs do in order to be part of that group that is seen as a driver of growth as opposed to just an expenditure of corporate resources? One, it's founded on the delivery of value. Obviously, if you have a lot of remediation to go do and fix a lot of operational issues, please go do that because it's the same even in a well-running IT shop. Whenever something goes wrong, it's like all of the oxygen in the room gets sucked over to that. But you get past that.
Then once you are consistently able to deliver value, you have credibility. Then with the credibility, Michael, I think comes the right to be at the table, to have a voice, and to be heard as part of the strategic discussions. Then I found that I had the opposite problem and I'm having the opposite good problem. Meaning, I get pulled in everywhere. If I look at the strategic pillars and our strategic objectives, it's difficult to find one where my name is not on it because everyone says, "I need this enablement. I need this capability.
Please help plug me into the ecosystem. What can I do with technology? What do you think about this?" Actually, once people view you as a credible partner, I think you very quickly find it's the opposite problem of everyone wants you at the same time. Again, it's a great problem to have because I think it reflects the underlying increasing importance of technology to what the company does. That says to me there is this real opportunity for CIOs but it definitely does require a different mindset, just looking at internal infrastructure and developing the skills and the relationships, as you emphasized earlier, with the business so that you're genuinely responding to their needs and that IT has the capability needed in order to respond to those needs and deliver the value that the business wants. Yes. The other thing, Michael, you just triggered
another thought. If you're getting started on that journey or you want to start, I think everyone is going to be at a slightly different place on their journey and what makes sense for their company. You can start small. One of the interesting things I've observed is you can use competition or kind of the natural instinct to be competitive in a good way on this. If you're just getting started, pick one high-profile project. Pick the most ready or the most mature business
group or business sponsor that you want to work with and make a success there. When we did that at Lenovo, I could tell, after we had a good discussion at the executive committee around the technology. You could see all the other business leaders. Because our CEO and chairman became very excited and said, "This is great," you could tell that all the other business group leaders said, "Oh, I want to be like that. How can I be the next person achieving that sort of success together?" That kind of starts a virtuous cycle, so it's not that you have to – like the movie Everything Everywhere All at Once (I think is the title), because that's very difficult. But I think, one by one, you can, if you're starting on this journey
or you want to start on the journey. You don't have to. You won't suddenly get there in one fell swoop, but you can absolutely take measured steps by speaking up, by finding the right partnerships, and that will give you the credibility on value delivery that lets you elevate the discussion. We have another question. Wayne Anderson comes back, and he says, "With January '23 upon us, even more jurisdictions have data sovereignty and privacy obligations. Where has this evolved your thinking over the last few years, this issue of data sovereignty and privacy?" I think it's certainly something that also is increasing weight in strategic dialog and conversations. Maybe I'll back up one step on this because it touches on a broader point, which is,
this is one of those compliance-oriented items. Of course, we are all going to comply with the relevant regulations and laws in all the countries and jurisdictions in which we do business. There have been studies that show. I saw one by Techaisle that was showing basically three-quarters of IT time is spent just on operations and keeping the lights on. This is part
of a trend which, if you're not careful, all your time just gets sucked into the back-office stuff, running the business, making sure it's compliant, tax, accounting, all that stuff. It's important, but it's not enough if you want to go back to, Michael, what you and I were just talking about. If you want to shape some of the investment discussions, if you want to be a partner and have a voice at the table about what technology can do, if you're spending 70%, 80% of your time saying, "I don't have the people or the people I do have are just making the machine run," that's not a good situation to be in. That's part of also delivering outcomes. One of the things that I'm trying to do (and our
solutions and services group) is let's deliver outcomes on the basics so that IT leaders can spend more time on strategic topics. Now, specifically about data sovereignty and data localization, I think it has really far-reaching ramifications. Even for us, we've had to think very differently about the architecture, and we've rearchitected to be able to accommodate and to be in compliance with the laws and regulations. If you think about major regulatory regimes around
the world (including China, the EU, America – and I think many countries are exploring) it's going to be a rising tide. We have had to rearchitect. We've rearchitected our core systems. We've rearchitected our data platform. We've rethought data capture. It's really an ongoing study because these things are changing constantly. You can't ignore it because someone is going to come knocking on your door and say, "Please demonstrate to me how you're compliant," in the various ways with the China data privacy law or with CCPA or whatever it is. Now it's different for the business because we had to say, "Hey, look. We have to take a pause here and rearchitect." Now, luckily, because it's also very high profile in the news, the business
understands. They see the march of regulation, and so they say, "Ah, okay. Yeah. Let's make sure we're on the right side of the law on this," and that's a fairly easy discussion to have. But it is real work to say what you want to be able to tell the business is, "Okay, we have an architecture that's extensible." It's fine if we have to take a delay one time. But if every time the law changes, it's minus three months or pushing out the schedule plus three months, that's not a good discussion, and so you have to be thoughtful about how you have the right architecture. Then I think, finally, the good news is there is
a lot of rhyming. The same way when GDPR came into force, many people studied it and, we'll say, took inspiration from it. I think that's of benefit because then it makes it more likely you can come up with an architecture that's largely extensible and reusable. If another country wants to have data onshore and wants to have data residency, well, you can use a similar solution rather than having to cook one up totally from scratch. Those are a couple of angles to think about. Another question on the planning aspect. How do you balance the need to make long-term investments in technology, as you were describing earlier, with the fact that, as a public company, you're measured on a quarterly basis? How do you balance long versus short-term? You have to have the alignment understanding that you're in it for the long term. At Lenovo, I'm
also very lucky in that our chairman and CEO said (especially now, at a time when we're trying to optimize expense and rebalance) the one thing that we remain committed to is doubling our R&D spend. We're a technology company. We believe technology will drive the future. And so, we can think about how to reallocate marketing, how to optimize other back-end functions, how to optimize and rebalance sales, but we will continue to be on the path to double our R&D. From the set and setting for me at Lenovo, I think the first thing is you'll be more advantaged if, at the company, there's an implicit or explicit (in our case) understanding that technology is the future we're going to invest. Now, regardless of the set and setting, whether or not you're at a company like Lenovo that's going to continue to double down, then it's about portfolio planning. Again, it's weights.
I think you don't want to get into the either/or trap. I think one of the key conjunctions is "and." We're all being asked to do this. We want to save money and rebalance and continue to drive the transformation and run smoothly. I think, Michael, what you said, the long and
short and medium terms is an extension of that. Then it just goes back to portfolio planning, which is to say these things are never black and white. You should never have to mortgage your future or sacrifice today. Those are probably overly simplistic frameworks, and so the portfolio of initiatives has been a very helpful mental model, as well as framework, to tell the company, "Look. We can dial things up and down." If we really want to overweight on short-term and short-term profitability and efficiency, then we'll take the portfolio. For example, instead of 60%, maybe we want that to be 75% this year. For the very long term and exploratory,
maybe instead of 10%, it'll be 5% this year. That way I think you can make it explicit on the tradeoffs you're making to show the shape of that portfolio as well as the implications. If you say, "Hey, our exploratory and long-term efforts we're going to have for the near term," then it does mean, your innovation pipeline, you may have a little bit of a hiccup. To our earlier point, what you don't want to do is surprise anyone. That's why, the visualization
of a portfolio, it's a simple two-by-two or three-by-three where you show timeframe as well as impact as well as the potential. You'd have that discussion together so that, regardless of the choice you make, you can make sure the company is taking explicit decisions and understands the implication that it has for the innovation and the delivery roadmap. What are some of the KPIs or the metrics that you use for evaluating your investment decisions? The first and foremost is going to be financial. We've evolved this over time because obviously,
a very important part of this is the business case to say whatever your metric is. We happen to use the ROI. Other companies use internal rate of return (IRR). There are a number of metrics you can use on the financial side. What we've had to do, in addition to meeting the hurdle rates on the financial side, we've had to layer in some additional categories so that we can capture the nuance. One of the things I believe you want to— The nuance, meaning not everything can be represented strictly by a dollar, and the world is a bit more nuanced in that. So, becoming overly financialized I
think causes bad behavior. We actually saw that. When the ROI was the only thing that mattered on whether you got a check or an X when you came to the investment committee, people started making things up. And so, what we had to do to become more balanced is we wanted the financial aspect, which is important but not the only one, is we started layering in strategic objectives, and we started layering in other things like regulation. We also layered in around the technology aspect. Will this contribute to building blocks (we refer to)? Will this create
strategic building blocks for the company? This is an area where I think you'll need a little bit of exploration to see what are the additional metrics you want to look at. For us, it's really around, does this make a strategic contribution? Does it create intellectual property? Does it create something that we can use for marketing value? These were things we found. We're like, "Well, it doesn't have the short-term return, but there are still things that we want to do over the long term." And so, we've introduced additional avenues to capture things that when we look— Sorry, Michael. Let me back up. Without getting too much into the weeds, those are some examples. The heuristic here was whenever we found the outcome from the decision machine, it felt weird. It's like, "By our metrics,
it says we shouldn't do this project. But this feels like something we should do." We would actually dig deeper to say, "Well, why is that?" and use that to refine, subtract, add to our decision framework and metrics. But the point is, on all the non-financial metrics, that's where you have to add or subject and reweight as the business changes. Again, your process is very oriented towards achieving the financial metrics and you have the technology goals, but very, very much ensuring that you're aligning with what the business actually needs. I don't mean to put words in your mouth, but it sounds like you use the data but you're also not a slave to the data. Yes, that's right. An example, and maybe as
another metric, we also – and it's not really a metric but a consideration. I think that's important holistically on go/no-go decisions for investments, which is, can we actually execute? We had a recent example, and just to maybe share some color on this one, where we said the key is don't assume money is always the answer. We were having some challenges where we wanted to improve, especially over the pandemic when everyone was struggling with supply chain disruption. We wanted to continue to protect our ability to deliver on time and on our commitment because we found people understood the overall environment. They were okay with slower delivery times. What they didn't like was lots of changes. "Is it coming Monday?" "No." "Tuesday?"
"No." "Wednesday?" "No. Next Friday." People got frustrated, so we wanted to call it once and call it right. Now, in our first iteration, we assumed money was the problem. So, we said, "Let's just give a few million dollars." Okay, we need $2 million to create the new capabilities, to put it into production, and have the new data models.
Then we found out that money wasn't the problem. When we went to check on it a quarter later, none of the money had been spent because the teams that were needed had all been pulled in other places on other priority initiatives. I think it's important to use the data. And you said it well. You don't want to be a slave, but you always want to see is it generating
the right outcome given what you've said. It's important to say not only do we run decisions through the decision-making model but that we're also examining the model itself and how it needs to be tuned and take into account new factors based on the business dynamics. I found that to be an interesting example. An interesting comment came in on Twitter from Jonathan Becker who has been a guest on CXOTalk, and he's president of the San Jose Sharks.
In response to your comment about CIOs moving beyond being a cost center to delivering value, he says, in strong terms, "Create value; don't just deliver value." It's an interesting point. Yeah. Maybe just to build on that for a second, I think having a CTO role has also been a part of that, which is, I think the tagline "Build the future." If we look at what we
have today on our solution and services group, and we look at our aspirations, there is a lot of room on this value creation. Of course, there's the incremental extension, so going back to what you said about the short and the long-term. There's plenty of low-hanging fruit that we're going to go optimize and build and extend onto the existing franchises and offerings that we have today. Now, at the same time, I think there's a lot more room in the medium to longer term to help figure out what's going to be net new. When we
talk about what's next generation, what's really going to be exciting from an experience from an outcome perspective that we can deliver? I think that's absolutely right. Deliver is, in some sense, "Here's what we know. Let's go make that happen." Create speaks to the possibility. And so, especially with respect to customers, the art of the possible is a wonderful discussion to be had when you're thinking about how can you deploy technology spend to go build that future. For many CIOs this notion of creating the value as
opposed to delivering services that add value ties to innovation and can be very challenging. Any thoughts on that? At the same time, Lisbeth Shaw on Twitter is asking more about the distinction between the CIO and CTO roles. We're about to run out of time, so I'll ask you to answer this complex, multi-faceted question pretty quickly. The CIO role is really around delivering and
transforming the company. The CTO role is around building the future, enhancing the portfolio so that we actually can have exciting offerings to our customers. What ties them together is the ability to think about and sense what's in the market. It's really sitting at the intersection. What's happening in the marketplace? What are customers saying? And then what does technology bring that can create something new? I think a lot of it is the remixing and the integration of existing and new technologies in novel ways applied to the context that you have in hand. That's ultimately what I think makes the CIO and CTO roles similar, which is, that's what you do all day for a living. You think about
complex business scenarios, and you think about this vast array of exciting technologies. And then it's about how you integrate it together in a way that makes sense for that context. Within that, I think it's quite empowering because that commonality is what allows you. Whether it's delivering value or creating value, you're just taking different lenses on a core muscle that I think seasoned technologists have been building over all these years. Is there tension for you between these two roles and the different demands of the two roles? Is there any type of conflict, would you say? There's definitely tension but in a positive way. One is on the time. Obviously, having two hats means having a lot more scope to look
after. And the other one is, notwithstanding what I said, it's still important to have an open mind. I never wanted to assume I can just take the CIO playbook and deploy it to the CTO. And so, I'm always trying to figure out what's similar (because the more things that are similar, the more I can use what I've already known to greater effect). And at the same time, there are new things. We talked about the mindset. We
talked about some of the much heavier customer orientation and how you layer that in when you are directly responsible for building and delivering something that's consumed in production by thousands of people around the world (outside of just the company). I think there are new elements around that. But I think the good part about that tension and why it's productive is I think it makes each role better because the CIO discipline helps with the CTO. The customer orientation and the listening and the sensing is helpful
also bringing that back into the CIO role. I think there's tension but in a productive way. Art, as we finish up, any advice for CIOs? We hear. It's not new to say that CIOs should be aligned with the business and support the business. But apparently, it must not be that easy to do because we're still talking about it as a challenge. What advice do you have, therefore, for CIOs for being the creator of innovation and value as opposed to just delivering services and goodness? Maybe three points to leave the viewers and listeners with. The first point is I think listening
really well is still extremely important because the first step in building trust is that you can have a dialog. I've seen too many people just talk about their projects and not really meet the business where they are. I think the ability to listen and integrate that to show that you understand what the problems are then gives you the opening to talk about what technology can do. Otherwise, sometimes that door isn't
even open. I'd say that would be the first one. The second part is really to speak up and to be very open in offering ideas and contributing to the flow of dialog around the executive and the senior teams because the more people will see you as having useful ideas that are relevant to their discussions, the more they're going to want to come to you. Then finally, I think you want to be the person of yes. I think a lot of people think of IT as, "Oh, they're the people who say, 'No, can't do that. That's too expensive. That's too risky.'" You want to enthusiastically say yes and emphasize, "Here is what we can do together." I actually went around the executive team to say, "Let's make this happen," because rather than analyzing risk all day, why don't we try? Let's put ourselves in a position to try something new, to learn, to create that value. I think those are the three points for
the viewers and the listeners to have in mind. I love that. CIOs should be the people who say yes. You know that's great and simple advice. Unfortunately, with that, we are out of time. I want to say a huge thank you to Arthur Hu. He is the chief information officer and CTO at Lenovo. Art, thank you so much for being here today. I really, really do appreciate it. Thank you for having me, Michael. It's great to start the year with you.
Everybody who watched, thank you as well, especially to those folks who ask such great questions. Before you go, please subscribe to our newsletter and hit the subscribe button to subscribe to our YouTube channel. Thanks so much, everybody. We have great shows coming up. Check out CXOTalk.com and we will see you again next time. Have a great day.
2023-01-26