Becoming an IT Leader: Theory vs. Practice

Transcript

Details

Mark Settle:  So I'm Mark Settle. I see some familiar faces in the audience. We're actually going to spend 45 minutes doing something that I thoroughly enjoy doing, which is talking IT shop. So we're going to talk about the inner workings of what really happens in IT and some of the issues and problems and pitfalls, etc. For the purposes of the next 45 minutes, even though you're sitting in the customer success track, I want you to think about this as the personal success track because there's going to be no Okta pitching or procrastination here or visionary statements about what's going to happen in Okta in the future, but really an opportunity to reflect on ways in which you can all enhance, extend your leadership capabilities within your respective organizations. 

You've been very gracious in the use of your time with us. You've given us up two days to think strategically about how you can leverage different types of identity management technology to safeguard the assets within your companies and organizations over the last two days. And so this is really just a little break or departure to think more strategically about your own careers and the skills that you need to be able to assume broader leadership roles again within your respective organizations.

We don't often get a chance to do that. You'll all be on planes probably within the next 24 hours and you'll be right back into the grind of the emails, drive by conversations and decisions, etc. A gentleman up here is wiping his brow just thinking about what's going to happen going back. And so I encourage you. I'm glad you've all taken this amount of time to spend with me and hopefully, you'll get some benefit out of this.

Now I actually have two objectives for this conversation and one is very ambitious and one is quite modest. So my ambitious goal is that I do actually material assist you in thinking about ways in which you can advance your careers in the future. My much more modest goal is that you walk away from here with one idea of something that you can either stop doing or do more or start doing in the future. There are many ways in which IT organizations and leaders make the same mistakes over and over again and I'm more than prepared to share a few of those with you today and hopefully help you avoid them.

Now why should I be standing up here talking about this? I've done this job seven times. Sometimes, I tell folks I'm going to keep doing this until I get it right. I'd go to some meetings where I get introduced and they say Mark's a seven-time CIO and that's great. My wife thinks I have a hard time holding a job. That's what her summary perspective of my career. And I've also had the good fortune not just to work in companies of very different size and scale, with different kinds of business models but also have developed a network of other CIOs. And when we commiserate over drinks or dinner, we frequently find we're all faced with many of the same challenges. We're struggling with many of the same problems. We've all made many of the same mistakes and there are many things that we would do differently, if we had it to do over again. So this is based not just on my experience but some of the lessons I've learned through my conversations with my peers.

Now there's kind of a safe harbor statement here at the bottom of the slide. I would be the first to acknowledge that each of you is in a organization that has its own unique challenges and opportunities, has a unique culture, and some of the things we'll talk about today need to be adapted to unique features of the situation that you find yourself in. They're not immediately applicable everywhere at all times, but I don't think you'll have that hard of a time adopting some of these ideas.

I was going to start by asking for a show of hands, how many people here manage money in some way, either a budget or a project or whatever? Excellent, excellent, excellent. Okay, thank you. And how about people management, virtual teams? Oh, my people, okay. So this will be very relevant. This is our agenda for the next 45 minutes. There's quite a wide range of skills that IT leaders need to be able to be successful and involve them on such things as managing talent, recruiting and developing talent, driving innovation within organizations, planning and implementing major initiatives and projects. But we're going to talk about two foundational skills today which are really essential to anybody's success. We'll focus on those initially.

Then you'll be pleased to know, we are going to have a group therapy session and talk about some of the common trials and tribulations. That's always a very popular part of the activity, followed by a very brief group prayer and then I'm going to send you away from today's session with a homework assignment, an individual homework assignment.

So I wish I could start our conversation about key leadership skills in IT by talking about something that's far more inspirational like technology innovation or business transformation or whatever. But the sad truth of it is IT organizations spend a lot of money. Now the amount of money varies a lot depending on your business model. With Visa, the two biggest expenses that we had were for our IT systems and marketing. That made up all of our operating expenses for all intents and purposes. And so again, it varies depending on our situation. But almost inevitably, there's a big bucket of money and there's a bunch of people that are doing IT, whatever that means in the organization.

One of the problems that IT suffers from is if you're in a different function like you're in manufacturing or you're in engineering or you're in sales and marketing, almost anybody in the company can connect the dots and figure out yeah, I guess we do need a sales organization because that's not a good thing if we don't have a sales organization, or we have to make stuff or build product to be able to have something to sell to make money. But most don't have any intuition at all about what goes on within the IT organization.

In fact one time, somebody said to me, said, "There's three guys over there that you have," and he named them. He said, "I think they are great but I have no idea what those other 397 people do whatsoever. I don't even know why you ... How can it possibly..." And I said you know we're over a 5,000-person company. If I had three people for every one person in the company, I'd be running a 15,000-person organization. So I think I'm doing a pretty good job keeping it down to 400 people. So again, there's a lot of ignorance about where the money goes and part of your responsibility as an IT leader is to educate people about that and to be very articulate and insightful and accurate about how the money is actually being spent.

So I've arranged a couple of topical highlights here of things that you should be prepared to discuss. Now the reason I had you raise your hands before, I meant to say, a lot of my observations come from the perspective of a CIO. But a lot of the lessons learned and the skills I'm going to suggest to you really apply to any IT person who's managing budget or people. It doesn't really matter what level you are in the organization. Ultimately, you're going to rub shoulders with business partners and business peers and you've got to be able to convince them that you're good stewards of the company's resources. And to do that, you have to be able to be conversant and accurate about your labor and non-labor expenses.

So again I'll remind you, there are many functions, take sales and marketing or HR, where most of their expenses are based on labor, the number of people in that particular function. They don't have a lot of non-labor expenses. So when you look at the amount of money IT is spending, they think there's a small army that you've hidden somewhere that must be chewing up all this money somewhere in the company. So it's important for people understand that distinction.

And then even within the labor expense category, almost every IT group cobbles together a portfolio of human resources where there are full-time employees, part-time employees, consultants, contractors, onshore, offshore, managed services, etc. and you have to be able to articulate why am I using that particular mix of human resources to get a job done. Are there unique skills that I can't get internally and I don't want to maintain on a full-time basis? Or am I just trying to cover bandwidth needs that I that on a transient basis going forward? And could I actually be saving the company some money if I have a recurring need for some bandwidth resources by converting contractors into permanent employees? So it's important to be able to be articulate about those different labor expense categories.

Vendor relations are important as well. So a poorly run IT group will lurch from one renewal conversation to the next with its vendors. A more enlightened IT group will look at their vendors in a more strategic way and if there are vendors that are providing similar or overlapping capabilities, you can try to co-term those contracts so that when they come up for renewal, you've got a bigger lever with the vendors to be able to negotiate a better deal or there may be unique terms and conditions. There may be warrants that you want to have for a failure to perform in the future or you may want to have some cap to the growth in future expenses in the event that you were to acquire another company or to go through some kind of a transformation in terms of the headcount within the company itself. So being articulate and insightful about how the vendors are servicing you instead of vice versa is very important.

Now the last three here are the turbocharged boosters, if you will, in really convincing your business peers that you're running IT like a business, and I hate that phrase but I use it anyway. The first is external cost comparisons. So when I arrived at Okta last July, the leader of my service desk team literally begged me for additional headcount. She said, "They keep hiring all these engineers and salespeople and whatever and we've been stuck down here with the same headcount for the last six or eight months and they keep hiring, hiring, hiring." So I said okay.

Well the first thing I did was I picked up the phone and I called six other CIOs in the Bay Area of similar sized companies and I just asked what's the ratio, like how many employees do you support and how big is your service desk team. It was pretty obvious that we had ... We were lagging, for sure. And that bit of comparative information was more than enough, more than sufficient to be able to go in and make the convincing argument that we needed to add some staff in that particular area.

You can also do more formal benchmarking studies. There's obviously third-party consulting firms that will take data about your data center operations or many other aspects of day-to-day IT activities and tell you how you're doing, first quartile to fourth quartile. And I'm sure many of you are aware, there are highly specialized consulting firms that can look at your telecom contracts or your Microsoft ELA agreement who are very, very current with the pricing and the terms and conditions that some of those major vendors are currently using. So that gives you a lot of insight into being able to strike better deals and obtaining best industry terms and conditions when you go through those kind of negotiations.

The highest form of the art here is to be able to discuss your costs in a very different way. So the trap to avoid is don't get stuck in talking about my travel expenses and my software expenses and my hardware expenses, which frankly doesn't mean a lot to most people. If you can associate cost into buckets, and this doesn't have to be a precise kind of an affair. But for example, when it comes to security, you say, "Well you know, I've got a security team, I've got a security operation center, I have security software, I have consultants that come in and look over our shoulder, do these pen tests. These are my cost over a year for security. That's what it cost, you know I mean? Security's not the most discretionary thing in the world and we're going to ... Do you want me to spend less on security?"

Let's have a security conversation instead of a travel consultant software conversation. And there are obviously other examples around activities that are essential that need to be performed. In a fast-growing company like ours, I look at our budget and I tell the CFO, "Every time you hire a new person, I have to give them a laptop and then we have to give them a subscription to Box and they have to get their tools on top of the desktop, etc. If you stop hiring, my budget will ... They'll be good for my budget. I won't spend as much money. So just try to do that for a change."

And in the function-driven, again, we talked about those other functional areas like sales and marketing or manufacturing where it's just intuitively obvious to the entire business management team that absolutely, we've got to keep the factory up and running or we've got to have a supply chain or we're going to have a distribution channel for our products. And so again, if you can associate costs with some of those business critical activities, it's a much a better conversation to have at the end of the day.

So I understand that you may not all deal with all of these costs but I just used them by way of example that those cost that come under your purview, you should be articulate about and I would encourage you to bring up those kind of discussions. Don't wait to be put on the defensive by a business peer but try to, when you have any opportunity, explain how you're actually using the company's resources to support a particular project or activity or functional team. So following the money is very important in being able to establish financial credibility.

The other is to confront and master the spending pendulum paradox. So this is a phenomena that can give any IT leader a migraine headache. You can go to a meeting in the morning with a team that is aggressively planning the roll out of the next generation telepathic ecommerce platform that's going to triple sales. And then you can go to a meeting in the afternoon where you're trying to reduce the cost of data center operations and figuring out could we offshore some of the staff and maybe move to a managed service, etc., etc. So the pendulum swings back and forth at all times.

Some of the factors that typically contribute to increases in IT spending are shown on your right. So there may be a competitive opportunity. Maybe a way your competitors has implemented a capability on a smartphone and you don't have that capability. Well guess what, we might need to put the other mobile apps team and chase that and not let that get away from us. You may have an executive that's come in from another company who says, "Well, the way we did it in my last company is way different than the way you guys are ... We need to do that like right now. That's why you brought me in here." So then we open up the checkbook and start to spend money. I've seen that happen many times.

And finally, when you have mergers and acquisitions. In many cases, the acquired company has got a mess on its hands and you've got a mess on your hands and usually, that was the opportunity to say maybe we could make our collective messes a little less messy if we will actually spend a little money for a change and upgrade to ... Don't make me move that antiquated equipment they have in their data center and put it next to the antiquated equipment in my data center. Could we just find a way to move to the next generation technology? So those are some of the more common forces that would drive increase in IT spending.

On the other side of the ledger, bad quarter. I don't know if you ever had that experience. Word comes down from on high. We're going to tap the brakes, okay? Tap the brakes, just make sure if there's any discretionary thing going on out there, we could just push that off a little bit. The second cause, I hate to admit, IT screws things up. We've got a major initiative, it's gone over budget, I'm going to have to go in and ask for more money. And if I could just find some money of my own to throw into the pot, then it's not so much me having to fall on my sword. I can solve half it on my own. Can you get me the money to go solve the other half? So that can lead to contraction in spending plans.

I included here executive temper tantrums. So what do I mean by that? Again, if you think back to that cost category reference that I made before, I've personally been in situations where a CFO or a CEO will look at the operating expense budget and they'll tell, he'll observe or be told, "Oh, our travel expenses have gone up 20% year over year. Our use of consultants has increased by 25%." Now there's probably a good reason why the consultants went up 25. He may have personally launched initiatives that required consultants that required the 25%. But again, there will be an immediate commandment that will go out that is we are not going to spend ... Tell everybody their travel budget is cut in half for the rest of the year because this is just unconscionable that we would actually spend this much money on travel.

And then the last force that can come into play is internal taxes, and this happens when there's sometimes a legitimate business opportunity. For example, you want to expand your sales team in Asia-Pac, again, maybe to meet a competitive threat. And so all the functions including IT are expected to reduce our budgets by a certain percent for the remaining part of the year so the funds can be diverted to go out and hire those additional sales folks.

So the consequence of this is that cost-cutting is a year-round sport and you never want to be caught without a hand of cards. So I want you to all come up with, in your minds, with the stereotypical model that you have of a riverboat gambler with a mustache, maybe hat, and holding a set of cards. So it's very important to be able to play the cost-cutting game to understand where you do have cost savings opportunities within your organization.

Believe it or not, no matter how friendly they are and how loyal they are, many times the people who work for you or report to you, they have sandbagged you, they have reserve, they know where some of these hidden pots of opportunity actually exist. But they're holding on to that money in the event that they screw something up so they can cover their own tails. So it's important. In fact, when you think about it, the incentive systems in most IT organizations all incent people to spend more money. Let's have a new project, let's go buy new hardware, let's go get some new software in here, let's get some people that know how to do something we've never done before. We rarely incent people for finding ways to save money and that's a fatal flaw in a lot of organizations.

So now I'm going to take you to the game and you're the gambler and you're there with the cards in your hand. And one of these issues on the left has come up and it's time to find some savings opportunities within your organization. You have to be careful about how quickly you lay the cards down on the table. Now I've been in situations where I was a good boy scout and I was given a number and I went out and I looked, found it, came back. They said, "Wow, that was pretty fast you're able to do that. Do you think you could go back and find me another?" So that can be a problem.

Now equally fatal and probably more career limiting is to fall in your sword and go to the world of IT purity and say it's impossible. I cannot run this thing with less money. It's impossible. There's no possible way this could actually be done. If you say it's not possible too many times, then they're going to hire somebody who will tell them it is possible. You can't be the last person to put the last card down at the table. And your job in a leadership role is to understand where those opportunities exist.

And again I said at the beginning, it doesn't really matter what level responsibility you have. You'd be running a project. Can you get the contractors off the project earlier than originally planned? Can you move up the go-live date? Can we do something different with training, maybe train some super users and let them go off and I'll train the rest of the folks. There's always ways to do things differently and too many times, IT folks are purists and they, I think, they have a hard time thinking about ways they could actually spend less money. It's just not in our DNA. We have to admit that.

So we talked about following the money. We've talked about the spending pendulum. And I'm sure many of you are aware that IT people are motivated to try to explain why we're spending all this money, and one of the ways that we frequently attempt to do that is to build chargeback systems. Now if you've never built a chargeback system or you go back to that conversation we had before about activity-driven cost so you might have a bucket of cost around your data warehousing activities or maybe your telecom expenses and user computing or whatever.

In other large organization with multiple divisions or functions, you create the buckets and then you come up with some kind of a metric to spread those costs out and charge them back into the business. And user computing is one of the easiest things. You can figure out what we're spending for the hardware that we give to the employees, the software that they need to get their jobs done, the desktop productivity applications, and the service desk support that they get. Put all those costs together, figure out how many employees we have and every division has to [inaudible 00:20:11] share of the pot to be able to cover those kinds of expenses.

I've seen a lot organizations when you initiate a project to build a chargeback system, IT people flock to this idea. They think, "Finally, we are going to be able to explain to the business why we spend a hundred million dollars every year, that the scales will fall from their eyes once we get this thing working and they will understand and accept why we're going to charge division A $30 million next year."

So what's some of the reality? That's the theory. What's some of the reality? The reality is these things are never free and what I've discovered is when the construction phase is underway, everybody in IT wants to get in, they all want to help and figure this thing out. Once it's running and it needs to be maintained and enhanced over time as conditions change, nobody wants to be involved in this at all. You had to go find two people to run through. Somebody's nodding over here. They've been to this movie.

They're rarely credible. Now what do I mean by that? So the example I gave you about the end user computing cost, yeah, that's pretty obvious. That's pretty straightforward. But you start to look in other places and inevitably, you've had to make some assumptions and the assumptions, much like the US tax code, are open to multiple interpretations. Now I was in one company where we have implemented our order to cash process on the mainframe. And so we knew our mainframe expenses and we knew these orders that we're going through, so we decided the mainframe doesn't know the difference between different kind of orders so we'll just portion out the cost in the mainframe on the orders that get processed for each division.

The problem with that approach was we had one division that had a very limited number of large dollar orders and then we had another division which had a lot of small dollar orders. So by doing this and allocating the cost on the transaction basis, the division with the small transactions was actually subsidizing the use of the mainframe by the division that had the larger dollar orders because they had fewer transactions going through. If we flip and done it the other way, it would've been unfair or perceived to be unfair by that other division. So the point being these things, the results look interesting but once you start chipping away and the business comes back and says, "Why is that my charge?" There'll be assumptions underneath that they'll almost inevitably challenge.

And the last and probably the most worrisome aspect of this whole enterprise is that they're seldom effective. So you really do this for two reasons. One, you tried to constrain demand. You think well gee, if they see the cost, they understand what's being charged to them, they'll take steps to reduce cost. So here's a good example. Small division gets charged for the Oracle ERP system. The head of the division says, "I don't want that or I never ordered the Oracle ERP system. I can run this thing on NetSuite or some kind of a small ..."

So go to the CFO and say, "Yeah, that division wants to come off of Oracle. They want to go do their own." The CFO is not going to do that. That's just not going to happen nine times out of ten. And then many other examples that you don't provide different services to different arms of the company. Think about your telecom expenses or the laptops that you provide. There's not a caste system in which different divisions get different kinds of tools typically. So they didn't really have any influence on demand whatsoever.

And finally, the transparency doesn't change the perception that IT cost too much. This is one of my favorite stories in the same company that was using the mainframe. We built one of these systems and we had 14 cost buckets, we had 14 services that we were delivering and we apportioned them over six different divisions. And every year as we went through our budgeting cycle, I'd make a presentation to the division president about what is charged from us, what's going to be for the next year. So we had a 90-minute review. We explained each of the 14 service categories and how his organization had used them the year before and why we had adjusted the charges for the year going forward.

We got to the end of this whole conversation and he looked at me and he said, "I understand exactly what you've done but I'm telling you, it still cost too much. You have got to go find a way to make it cost less." I said, "You want less data work?" "I don't know. But just, it's too much. You don't understand. I have P&L to run. When you charge this to my P&L, I just cannot assume this kind of cost." So the beware here is don't do a lot of work, doing something elaborate that can be easily challenged that doesn't really address any of the fundamental problems you're trying to solve to start with.

And not to belabor this but many of the same points could be made with regard to business cases. Sometimes IT organizations get obsessive about business cases. They can build things that look good numerically but there are a lot of elements of the case that appeal to productivity improvements within existing workforce or avoided cost in the future. I had an executive at one company who said don't ever bring another business case with productivity improvements. I think I bought the same productivity improvements in the last six IT projects that I approved. I'm going to do that again.

This is one of the more embarrassing stories which I'm going to share with you. I was interviewing with a tech company in Southern California several years ago and when I got to the part, to the interview when I was meeting with the CFO, I don't know how this got started but I went off on business cases. I shared with him my observations about best practices, how you build a business case and all that. So I finished this list, took five minutes or so. I finished the whole conversation and he says, “Well, I never believed anything at a business case.” He said, "Anybody can move the numbers around. I don't think there's anything about that."

So I go to those meetings because I want to see the business executive who's sponsoring this. I'm looking for passion. That's the only [inaudible 00:25:48]. If somebody is viscerally committed to using this to do something good for the company, I'm all in. But if I tease he's wandered around and cobbled the other some costs and come up with some numbers and has grudging or lukewarm commitment from different parts of the business, I don't want to touch that project. That's a bad use of company resources.

So passion is an important element and probably much more persuasive than some over-engineered business cases. So I've probably driven this into the ground but you understand that financial credibility is a super important foundational skill, and you shouldn't wait to be challenged to show that you're being good stewards of the company's resources. You should find opportunities to share your insights and observations about the steps you're taking to do a good job in managing money.

The second thing we're going to talk about are business relationships. So to introduce that conversation, I want to talk about the three paths to value creation. When you're an IT leader, there's really three things you can do that would generate value to the company or organization. First, you can look inward and make IT itself more efficient and effective. We all have to do that. Second, you can partner with folks in the business and try to re-engineer their processes, which in many cases can have a significant impact. It actually lead to improvements and revenue, productivity, profitability, etc. And then the last is true business transformation, where you leverage technology to potentially open up a new line of business, address the new customer demographic, expand into a new geographic region, open up a new distribution channel, etc.

Now, it's not as if you come to work every day in a leadership role and decide, "Gee, today I think I want to do some business transformation work. I'd just love to jump on and get in some of those conversations," etc. You have to earn your way through these three different circles that are here. You got to be able to show that you're running your own operations efficiently, that you've actually partnered with the business successfully in the past in some capacity through some of these re-engineering projects, and that lets you get to the big boy table and start talking about longer term company strategies.

If you haven't shown your business worth and the other half of this conversation is if they don't like you, if you're the tech guy that can't get past three sentences well and acronym, even though you may have done good things, they're going to think, "Let's get Accenture in here because at least I like those guys and I can talk to them. I can even talk to my own guys." So these things are not all up for grabs. They're not all jump balls every day. You don't get to decide which one you want to work on. You earn your way through.

So what are some of the common mistakes that people make in terms of business relationship management? So you'll go to many Gartner meetings and read a lot of research, reports about aligning with the business. So why does it go so terribly wrong so many times? One of the reasons is IT people love to focus on far more over substance. So a lot of people would say, “Oh no, I rub shoulders with the business guys. We have these regularly scheduled meetings. I go to the meeting with the 20 people and I'm there. We don't really talk directly but I watch the PowerPoint slides and I ask a question or two and I'm one of the guys. I go to this thing.” So that's not really a relationship. That's just a common commitment to go to a meeting with a lot of people.

Emphasizing analysis over intuition. So many people in IT have engineering backgrounds and they think, "Well, if I really want to have a sense of conversation with somebody in the business, it's like a master's thesis. So I need to state a hypothesis, collect data, perform an analysis, and lead them logically to what to me is an obvious outcome of something we should go do, that would be good for the business." We need to calibrate your audience pretty careful here because as business execs get older and wiser, they make a lot of intuitive decisions. And I'm always amused, and I shouldn't smirk when I'm in these rooms, but you'll go to meetings where a senior person will say, "We only make data-driven decisions in this company. We are a data-driven company. That is how we operate."

All too often, people collect data to just reinforce their preconceived notions about the way things should work. They already know what they want to do, and the business case conversation is a good example of that. We are going to go build this econ platform. I just need to get an ROI of 300%. I don't care how you get there but we're going to get there and then we're going do this thing. So it's much more effective and insightful to understand some of those intuitive preconceptions that your audience may have than to run off and do some kind of an exhaustive analysis.

The third one that I would focus on here and call to your attention is settling for one dimensional relationships. And again, no disrespect intended to anybody here in the room but if you look at behavior of a lot of IT folks, people let them go to meetings and they sit in their office and do email. Go to the meeting, come back to the office, do email, go back to meeting, come back to office, do email. If you look at some of the other folks operating the business, there's much more casual interactions going on. Many more drive by conversations.

And I think a lot of times, IT people think I wouldn't want to be bothered in my office. I wouldn't want to be distracted by somebody just interrupting me. So of course, the CFO wouldn't want me to just come in with a cup of coffee and chat about the trip I took to Memphis last week and what I saw on the plant there because if he wanted that, then he'd invite me to come do that. The same way I invite people to come into my office and brief me about things that I'm interested in. So that can be a fatal mistake.

Now, there are two elements in my experience to a successful relationship. So I would refer to this as a two dimensional relationship. One is social and one is business. Almost every successful relationship I've had has had some kind of a social dimension to it. And the good thing is everybody wears their interests on their sleeve. It's really pretty rare to not be able to figure out what excites somebody in terms of the activities of their kids, the schools they went to, the sports they follow, etc. It's pretty easy to develop a casual conversation and develop that level of rapport or empathy with a business executive. That only gets you so far. That gets them to like you.

But you also want them to respect you and that only happens when you exhibit a very healthy intellectual curiosity about how the business works and how their responsibilities affect them. What are their challenges and opportunities? Spending time with business execs should be one of the imperatives that you think about in the way you use your own time. I've learned more in the United Club Lounge about the problems in our sales organization than I've learned by going to four all day ops reviews about what's not. You find out the incentive plan is what screwed it up. Brawl with like our.. they can sell stuff but look what we did with the incentive plan. They're not going to throw those darts necessarily in a room with 30 people, but you see them within the club lounge and you'll find out. So any opportunity to travel or have a meal with somebody in the business can be hugely impactful, and even go into their meetings. Just living their world is important.

Now this is one of my favorite stories to tell. A good example of this was a relationship that I developed with a CFO in a prior life. So it was Arrow Electronics because it's ... I'm going to tell you I was on Long Island at the time. So the CFO and I were early risers and we would get to the executive suite early in the day before anybody else and one or the other of us would make coffee. So it turned out he and I were both Yankee fans. And I don't know how many people here are from New York but if you're from New York, you can talk about the Yankees ad nauseam. So we would critique the game from the night before, who dropped the ball, what was a bad call, it a missed call, why did they trade for that guy, how come they traded away the other guy who, by the way, he had a home run for the Indians the night before or whatever. So we had this casual conversation. We got to be pretty good buddies.

When it came time for budgeting every year, he would give me a budget mark. He'd say, “Okay, this is the number that I want you to hit.” And I'd go in to see him, not during the coffee bar. I go see him and say, “You know what, I don't want to do that. I really need this much but I think I can get by somewhere in the middle. This is where I want to end.” And we have a handshake agreement. I could get to my final number in 30 minutes. I didn't have to take all that time because he trusted me and we had the social relationship that I talked about before. So I highly encourage you to think about the duality of this kind of relationships and to decide where you need to invest your time either on the social or the business side with some of the key execs that you deal with.

Three other quick watch outs. So one is failing to make regular deposits in the relationship bank. So let's just say that you had an experience where you work closely with a marketing organization. You developed great relationships with them but you've been distracted for the last four, five, six months and you haven't really been rubbing shoulders or keeping up with your friends over on that side of the company. And then all of a sudden you realize, you know what, I need their support for money or we, IT, screwed something up and I have to go ask for forgiveness. And they haven't seen me for four months and now I'm going to go over there and say, "You know, the website went down because," or "We found this whole new tool that's going to increase lead conversion and I'd like you to help me," whatever but it's like who are you? I haven't even seen you for four months. You've been playing with the manufacturing guys.

So making little notes in your calendar that say it's been a couple of months, I really need to go over there and have lunch with so and so or do a drive by, a coffee chat, or something is definitely a recommended activity. You can be poisoned by members of your own team. So you may have service managers or business systems analysts who are wandering around different functional groups who are incredibly frustrated, who will come back and tell you they're Neanderthals, they don't understand technology, they never want to change. I have worked with them. I can't take it any longer. I'll keep doing my job but for you to go over there and try to get them excited about this grand idea that you have is a complete waste of your time. I'm telling you that right now.

So I learned my lesson about that from a gentleman named C. Michael Armstrong. So C. Michael was the CEO of AT&T, and before the CIO jobs that you saw listed there before, I worked for Hughes Aircraft for several years. So C. Michael was hired to be the CEO at Hughes Aircraft and he came to AT&T. So the first 90 days that he was the CEO, he never came to corporate headquarters. He flew around and visited all of our customers and major suppliers. And as you might imagine, the corporate staff was apoplectic, like we've got to talk to this guy. We need to tell him what's wrong and the challenges we’re facing and everything. So when he came back, he had this town hall thing. We're curious like why don't ...

He said well, what I experience is if I listen to my own people, they keep telling me the problem is the customers. The customers don't understand the product that we're trying to sell them. Or the competitors, they got lucky like they stumbled on this thing. Or our suppliers, they're killing us. We can't be profitable with the terms that we're able to wrangle. And he said, “I get a very different story when I talk to people on the outside of the company looking into the function, into the company as opposed to the folks that are actually inside running things day to day.” So I think the same thing is true of IT. It's very easy for your own staff to poison you with a lot of preconceptions about what other organizations will or won't do.

And finally, building relationships that are easy instead of those that count. So as I'm sure everybody's aware in your company, there are some functions that drive revenue or profitability that have a golden voice. They're the big guys. They get what they want. They keep what they want and they help set the direction of the company. If you're not careful, you may find yourself developing your best relationships with groups that are not as impactful or maybe because they're easier to get to. Maybe it's HR organization. Your corporate headquarters, their corporate headquarters, well they're really easy to work with.

But guess what, the manufacturing guys, they run out of Indianapolis and I don't get out there too frequently or whatever. Well guess what, that may be the most leveraging relationship that you need if there's going to be a budget cut by next year or we're going to go through some major convulsion within the company. The support of that individual in Indianapolis could be far more critical than the head of the HR group. So you got to face up and figure out what are those driving functions.

Now for me, it's easy within the enterprise software firm. The only two functions that really count in enterprise software firm are the guys that build the product and the guys that sell it. And you owe your buyers in this marketplace and you've all seen the landscape of software companies that can build a great product but have no idea how to sell it and others who build a product but can sell the hell out. So it's easy for me to figure out who my key relationships are in a company like Okta.

Now is the group therapy session. I don't know if you've ever read Gulliver's Travels by Jonathan Swift in the early 1700s. But Gulliver was a fictional character, an Englishman who was shipwrecked and landed on the island of Lilliput. And the Lilliputians are all six inches high and he was unconscious when he was brought on shore, and so they tied him down because he looked like a monster to them. So here's this strapping Englishmen, strong, smart, whatever, who's immobilized by the Lilliputians.

I really can't think of a better analogy for an IT organization because most IT organizations have got tremendous technology, hardworking people who are dedicated and want to have a business impact. But you look around at all the problems that you have and you confront some of the issues that are listed here. Limited budgets, limitation on your staffing research, skill gaps, what you have versus what you really need, increasing regulatory requirements.

I'm not going to read these all off but if you're not careful, this becomes a pervasive blame game in which the staff is commiserating around. No wonder we can't get anywhere around here. We have to deal with all of this. Well it's pretty obvious as a leader, you can't join or lead the blame game. You've got to overcome the blame game and one of the easiest ways to do that is by praying. So this is our group prayer. So I don’t know if you're familiar with the serenity prayer. I didn’t make this up, it really exists. It really is the serenity prayer and the serenity prayer says, “God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.”

And if you go back and we look at ... Let’s go back. If you look at those things, let's face it, a lot of those are just not going to change. IT doesn't get to pick the budget at once. You get the budget that they can afford. There will always be skill gaps. Technology's going to move forward. You're going to have legacy systems. That's a perpetual phenomenon. It's like you're never going to catch the skills up and say we're done with that problem. So these are technical debt will be with us forever. So you really have to be able to focus on areas where you can make a difference.

So I have three suggestions for you here. So first, prioritize and simplify. I really hate to admit this but probably almost every IT organization I've ever been involved in, many of the people on the staff would just like to be told what's the most important thing that I'm supposed to do today. I got production support issues. I got sustaining engineering projects. You've put me on three other projects and I'm supposed to do something and my buddies in the business are calling in from the outside saying, “Hey, I got a problem. Can I ask this with you and get this done because it's not happening outside of the normal channels or whatever? So could you jump on this right away and help me out?”

The problem gets compounded because most of the managers in IT like to go to other meetings and then just make further commitments. So somebody brings up a problem and they say, "Gee, I think I could probably help with that. I'll get back to you on that." They have no idea the body of work. So literally, people come to work and we almost leave it to our exempt employees to figure it out on their own. We can figure it out. I didn't stay out late last night. This were some production support issues, put off that project deadline.

So there's very little understanding about how some of the decisions that they make as individuals really affect downstream activities or project completion timelines, etc., etc. So there's tremendous benefits that can be obtained through just a simple prioritization of work and it's.. so let's move on to the second. And then the second is manufacture headcount. So again, I have never been in a shop where every manager at any level said if I only had 10% more heads. I could move a mountain if I just had two more people in this group. I got all these plans for that.

The sad truth is they're probably frittering away the productivity of people in the group because of all the hand offs that go on within the organization in this chaotic entropy that occurs in so many groups. So part of your responsibility as a leader is can you reduce some of the bureaucracy, the hand offs, the ticketing systems, etc. and can you drive fewer labor touches, more automation through the organization. It's really paradoxical that we've all embraced agile as a software engineering methodology when there's so many internal operational practices that would benefit through just simple scrum meetings where people understood how the tasks that they're responsible for impact downstream activities that are going on, or how their peers are waiting for them to get through something done, that the peer needs to go off and to be able to accomplish something that's on his or her timeline.

So any good IT leader should be looking to the mirror and try to figure out things that I can do myself. Automation, I also have some strong convictions on. All too often, we buy automation tools and let different groups go off and do different things. In that kind of situation, there's very little opportunity for reuse and you don't really see any kind of pervasive effect. You may have some spot successes but no real organization-wide improvement. Again, it takes a bit of enlightened approach to actually say I'm going to put some headcount and buy some tools and then develop and use them consistently across the organization.

And then the last is stop hiding behind the annual performance review, the succession planning exercise, the employee engagement survey, the high potential planning meetings, etc., etc., and just give people a little feedback. This is one of the most criminal things that happens within an IT organization. We have so many ongoing activities that there are incredible opportunities for just bite-sized feedback of how could you do that presentation better. How could we have gotten to the finish line faster, etc. If you ever get turned out of work and land in a consulting company, believe me, any engagement you go into, you'll get a lot of feedback.

If the engagement manager doesn't like the way you presented something, doesn't like the way you answered a question, things you could have done better, you will have that feedback probably within 10 minutes of the customer leaving the room because it is so important to continue the business relationship that the consulting firm has with the partner. Another good example is sports, football teams. One of the reasons that people practice is so during the practice, the coach can go up and give bite-sized feedback.

The interesting thing about a lot of coaching if you ... I've learned this from the defensive coordinator of the Texans, he said I only give coaching when I touched somebody. So when somebody's done something I think could be done better, I go to them on the field and I touch them. And then I tell them what they could've done better. That's my way of saying this is important to me like I want you to pay attention. So I would recommend to you that bite-sized feedback can be far more effective. I don't think annual performance we use frankly accomplish a whole lot at the end of the day.

So we said our prayer. There's some opportunities here for personal improvement, and I'm going to end with a homework assignment. So although most companies like to talk about career development, let's face it, it's really more about like what can you do for the company than what the company can do for you at the end of the day. You have skills, experience, knowledge, relationships that they want to mine and leverage and apply to their business problems and make them more successful which is great, which is why you signed up. You want to be challenged. You want to exercise those muscles that you developed over time. But if you're not careful, it can become a one-way street.

So look at the mind picture there. It's like every year of spending time with the company, they're just digging you down to another level and just extracting your energy and knowledge and skills. What I recommend to all of you, this is your homework assignment and you're going to like this because this is not like go home and do it this weekend. I recommend this over the Christmas holidays because I've done this myself over the Christmas holidays.

Do an IQ test on yourself and ask yourself over the last year, have I been exposed to really significantly new technology or technology practices? Did we really get into DevOps, understand how DevOps works? Did I really get into like mobile apps and now I see that how the whole world actually operates? Did working at company X really take me in that direction? Second IQ dimension is business. So did I just continue to support sales and marketing and I did that for the last three years and I really understand how the sales and marketing process works around here but I have no idea how the engineers do their stuff or how we run our distribution channel, etc.? You don't necessarily need to move to a new company to get more business knowledge. You just need to operate in different parts of your existing company.

And finally, people management. Again, a lot of people would look at this and say, "Oh, that means I have to manage more people." That doesn't mean that at all. Did I manage a virtual team that was spread out over multiple geographies? Did I manage a team that had different cultures? Did I manage a team that had more executive visibility where I was coordinating activities across different levels of our organizational hierarchy? Was I challenged in some way and develop better people management skills?

Now if you do something like this over the Christmas holidays, I suggest you ... Index cards have been out of fashion but you can find something to make a note on one of the pads from the Aria. And slip it in your sock drawer and then look at it a year later and then you’ll know it really didn't change that much. That's when you really want to start seriously thinking about whether you can initiate change on your own or whether you really need to look somewhere else. And again, companies are very well-meaning and they do provide opportunities for people in many of the dimensions that we're seeing here. But those opportunities are not evenly distributed, and if you feel like you haven't had your fair share of opportunity, you need to proactively seek ways to extend your leadership skills.

So the good news is you didn't have to pay any attention today during the last 45 minutes because there's an incredibly insightful book on this topic which is called Truth from the Trenches. So I wrote Truth from the Trenches, I'm keeping you but you seem to be entertained, in four weeks. I wrote it in January of 2014. I have been keeping notes on my experiences in a Manila folder for several years because I have my professional bucket list. I thought I've got to write this stuff. You can't make some of this stuff up and it's like the movie Groundhog Day or The Matrix because it seems like we keep doing the same thing wrong over and how can this possibly be?

So this was an exercise in personal therapy and catharsis, and so I'm more than happy to share it with you. There are copies at the back of the room which you're welcome to take. If we run out of copies or you'd like to continue this conversation, my email address is pretty obvious. You shouldn't have trouble reaching me. And I would encourage you, I'd be more than happy to continue the conversation with anybody in the room. Fortunately, we ran out of time so there's no way that you can challenge me or anything. So let's all go to lunch. But thank you so much for your attention.

You’ve escaped the day-to-day demands on your time by coming to Oktane. Why not join Mark Settle – seven time CIO and author of Truth from the Trenches – for a coaching session on the key traits and practices of successful IT leaders? Before you return to the office and resume your normal responsibilities, learn some of the time-tested tips & tricks that successful IT execs use to make their teams more effective and advance their own careers. This is the perfect session for emerging IT leaders trying to take their careers to the next level – spend 45 minutes with one of the best IT career coaches you’ll ever meet!