Dan Smith's reflections of a CIO on his use of requisite organization methods at Southern California Edison and Commonwealth Industries in redesign of complex IT systems

Ken Shepard:   Welcome to a global organization Design Society's audio presentation this is part of a comprehensive and evolving web based professional development program. Learning resources include e learning modules, video interviews, videos of conference presentations, audio of interviews like this one, PowerPoints, books, articles, and dissertation materials are without charge to nonprofit executives and board members, and also to academics and graduate students. There is a modest charge for some materials to those in the private sector. We have prepared this audio track for your convenience to download and listen to while you drive or exercise. Today's interview is with Dr. Daniel L. Smith, a fellow of the global organization Design Society and principal of leadership solutions four. He is a specialist in organizational and hr analytics and organization design. We are focusing today on Dr. Smith's experience in a number of transformation roles at Southern California Edison and as CIO at Commonwealth Industries. Our topic will be organizing to leverage information technology and will cover such issues as discovering the importance of levels of human capability and leadership development, and redesigning a large it function with many benefits. The interviewers are Ken Shepard, president of the society, and Jerry Luftman, managing director of the Global Institute for IT Management. Now let's get started.

Dan Smith:  I've completed my graduate studies in the field of measurement and evaluation, heavy emphasis in statistics and analytic methods, experimental design, and so on at the University of Southern California. I was teaching in the graduate PhD program as well at the California School of Professional Psychology and in general was building career preparation for work as an industrial psychologist and organization consultant. My focus was in the traditional arenas of team work, communication, conflict management, et cetera, and my skill sets led me to work in the area of surveys and analysis of questionnaire projects and so on. My first professional work, in the sense of full time corporate work came when I was recruited and hired as an industrial psychologist at Southern California Edison Company. This was in the, oh gosh, very late 70s, maybe 1980 even, and Edison, as most utilities still do, had very strong internal professional teams working in the arena of formal personnel selection testing. Most of the job progressions in utility industry are unionized and are controlled by human resource development rules and job progression rules and based on test measurements of job knowledge and job aptitude, et cetera. This was also the arena when in the human resource field, the world of job validation, sorry, personnel procedures and personnel selection procedure validation was critical because it was only a couple of years after the major Duke power cases and McDonald Douglas case and a couple others that defined the new terrain of job related HR post affirmative action, post CEO HR, and it was a very exciting time. And Southern California Edison was, and still is, top five business throughout California was a very well run and very well resourced organization. And those of us working in the industrial psychology group were involved in all aspects of personnel selection, systems building and other kinds of research projects as well. Today we'd call those talent development recruiting standards, system building, performance management. From a very early stages. My work was in that arena not long after I was in the personnel selection area and I was recruited as administrator for the management development programs and then soon after that made corporate manager of human resource development. Now this was in golly, I'm going to say 1980, so I would have been 20. I was born in 46. So what's 19, 80, 34 years old. So at age 34, as a benchmark, Ken, I was working as corporate manager. Today we think of as a director responsible for human resource development for Edison's management workforce, non union workforce, and corporate general skills training. Our group ran all of the tuition reimbursement programs and we interface with the key universities in the area, USC, UCLA, Caltech, around standards and eligibility for corporate funded college programs, et cetera. And in that context, I had occasion to lead a corporate committee for development of an executive development program largely oriented around identifying high potentials and putting in place the general educational programming to prepare them for advancement as they moved up through operations roles and then do executive work. In that context, I contacted a number of thought leaders around the country. Edison and my work at Edison involved me in corporate committee work in the utility industry through the Industry association, the Edison Electric Institute. And I was on several committees working on industry change projects and also executive development programming at the industry association level. And in that context, I've met a professor at University of Southern California, Dr. Catherine Burke, who subsequently I'll refer to as Katie. And I think most people in work levels based field just know her as Katie. She's widely known. I reached out to her because Elliot Jackson's work in organization structure and organization design principles, levels of work based approaches to work, had been identified as a potentially useful field, potentially useful reference point, and we were interested in it as a way to give us some consistency and guide on how to build our executive programs. This is the beginning, Jerry, of that question for why? In my judgment, the levels of work based approaches offer a very capable and potent tool. And in a part at the beginning of the answer, the question is why? I think it's better. Up until that time, the method of identifying talent and building development was largely based on fundamental principles. Like every manager replaces themselves, what matters is job knowledge and personality attributes. We were looking at quite a number of screening aptitude, screening instruments and screening exercises. We ran an assessment center, for example, and all of it was labeled in terms of personality or personality related attributes. Since that time, I've come to the view that most of the issues that were identified as key discriminators between high potential and more moderate capability manager had to do with their cognitive ability and their cognitive approach to the way they did their work. We also were looking for alternate approaches that would allow us to get past racial and gender laden criteria. So if you use things, the normal indicators for career advancement, like previous jobs held, they tended to be artificially biased towards people who had already been in those kinds of jobs. So we were trying to look for anything in the research arena that would, from the get go, be presented and approached as a non. Help me, Ken, with the word. I'm looking for things that are non biased by gender. Yeah, unbiased and non gender, and non biologically related and non culture related. We wanted that neutral selection tool. And the research and the statistics that was underway were really very favorable towards the levels of work based approach. Still to this was it 30 years ago? I'm still not aware of any research that has given suggestion that there is in fact a differential racial or gender related bias in level of work capability. It seems to be the best available indicator that is not subject to cultural and biological racial dynamics.

Ken Shepard:   Just an interlude. Bioss, the firm that uses work levels in its assessment is big in South Africa, and apparently the work levels approach is the only approach they've found. And South Africa is one of the most sensitive to this bias against race and so forth. And I believe that is leading market share in large companies in South Africa.

Dan Smith:   And that lack of bias gave us a tool to think through, how to identify talent that may not have been on an accelerated career path in terms of their work history because of one or another bias factor, but who clearly showed signs that it could rapidly catch up, that under positioned talent, the hidden talent. And so we started to look at levels of work theory as a basis for putting in exercises and activities that would give visibility to high cognitive ability. And in so doing, we, myself and the project team that I managed and my own staff, we built proposals for executive development at Edison that would be centered around, for example, the key role of the manager once removed, rather than the immediate manager. And that was a very innovative and different thing to do. It was the first step in really exploring what it meant to think in terms of levels of work as a starting point. And so our early executive development programming involved reviewing input, even selection of the management. Development selection teams were geared towards the level of management, one level of management, above the managers of the target population. So when we were looking at candidates to move into director roles and to be developed toward director roles, rather than work with regional vice presidents, who would be the managers of the directors? We worked directly with department utility. At that time, they called them department heads. Today we would call them the enterprise or the subsidiary heads, the C suite. So that immediately upped the level of executive visibility and executive guidance and wound up picking a very substantially different group of people than might not ordinarily have been identified. So that's a second early experience in my history that encouraged and reinforced the hypothesis that levels of work would offer better, more useful tools. Is that the kind of data that speaks to your question, Jerry? That sense of what were those early things that made me start to think this could be something better?

Jerry Luft I still would like to hear at least a clarification of here's how I did it before, here's how I do it now. Here's why it's better.

Dan Smith:   Okay, let's take that early before and then after in the way the program was designed. Our objective in the executive development work was to identify a cohort of likely candidates for rapid movement who would then be exposed and also invited to participate in accelerated development activities, special project activities, training courses, enrollment and outside executive programs, et cetera. Mentoring. Before that, identification was made strictly on the basis of the classic human resource data points, performance reviews, the opinions of their immediate managers, and seniority, how long they'd been in the job, and what their job history was in terms of being ready for the next step in that same career path. The use of those data, of that data tended to identify people who were socially very compatible with the existing norm and were therefore great people who would go along to get along, get along to go along, and very, very low on issues, on talents associated with innovation, and transformational leadership. These are the terms we later came to use more regularly. Transformational leadership. When we used work levels, theory levels of work based analysis, the first issue was to analyze the level of work we were looking to resource to develop for and identify the jobs in the company who would have executive responsibility for those positions. And what we were looking for were not indicators like past job performance. That was a relevant matter, but it wasn't a determining matter. What we were looking for was signs and indicators of the way these people approached their work. And we found that we wound up with a different group of people, many were the same talented folks, but probably half were people who might not previously have been identified as high potential. Previously, they would have been identified more likely as oddballs, talented, but not really very good leaders, hard to work with, pushy, various terms that are associated with subordinates who are bringing to the table suggestions that are outside the normal boundaries of the mindset that's controlling their jobs. When we put those people into the development experiences, they tended to thrive. And when they were given an opportunity to work directly with their boss's boss in development, mentoring relationships, and special projects and presentations, they wound up being terrifically effective communicators. They knew how to relate. They talked in the same language, they saw things in the same sort of conceptual framework. And their boss's bosses, repeatedly, by repeatedly, I would say once a week, you'd have some boss's boss turn back and say, you know, I know that Betty was described as hard to work with, but I find her delightful. And so the before was we were tending to miss the high level talent and be biased towards social convention and organizational acceptability. After, we tended to find the hidden talent, and we were tended to select people who could handle the tasks that the developmental projects confronted them with. So we had higher quality project work in the development work. And one year we sent the. The leading executive program in the country is the University of Idaho's public utility executive program. It's been there for, since the 1950s. And one year Edison sent nine people who, who literally dominated the program. And that was sort of a change point for those of us involved at Edison, southern California Edison, in thinking in these terms now, nothing about our use of levels of work theory at that time was intended or approached as an organization culture change tool. We simply wanted to do a better job of finding talent and use tools that would allow us to avoid the biases of the utility culture. And by, through two to three years later, it was quite clear that that program was working just fine. And so before the, before and after would be judged in terms of the quality of the talent and the effectiveness of the program. I would now explain it in terms of finding what we were identifying, began to look at was the underlying cognitive capability of our talent and beginning to construct developmental activities that were designed to test that talent. So we created projects and created activities that were structured at the right level of capability and the right level of challenge. Is that closer?

Jerry Luftman:  That's much better. Daniel. Thank you.

Dan Smith:  Okay. And please press on that because I want to make sure I get to.

Jerry Luftman:  The details that are helpful because I could see having a generic set of data points for identifying high potential candidates and how you might want to move them up in the career ladders of an organization. But if we go to a specific job requirement where I'm looking for a candidate for a specific job like we're looking for, I'm talking about using this to identify a chief information officer. How would you use this approach and how would it be different than without the tool in identifying and selecting a specific candidate for a specific job?

Speaker B Great. That actually would allow me speaking to that point fits right into the rest of my comment on how did I learn about Ro and et cetera, have the IT role and the chief information officer role, et cetera become central to the story? My work and our team at the corporate HRD environment resulted in an invitation from Edison's vice president of information technology services, IT services, they call it, to move from my corporate role and become general manager of their internal staff training and organization development efforts inside the ITU department as a whole. Now this would mean moving from corporate to one of the line departments. And it was a bit of a culture shock when I took the deal, but it was actually very much based on what I was learning about levels of work, et cetera, what was going on in the IT department. Edison's corporate department IT department was one of the IBM top 100 customers. I think we had rated 83rd in largest data center data management, et cetera. Edison's customer base is 17 18 million customers, 17 or 18 million people in eight to 12 million or eight to 9 million accounts. They serve a 50,000 square mile territory from the Colorado river to central California to Mexico. All of the stuff that goes along with big. And in the mid 1980s, by this time, the fundamental dynamics were that the IT department was rolling out pcs in the whole development of networks. They were rewiring the company for improved communication capabilities. Big online systems were in development. Edison had about 1000 employees in their IT department and what was happening was their turnover rate was 22% within the development group and they couldn't find any more office space. All of the company owned offices in the general region of their corporate office were filled with either Edison employed it people or they were rented space where Edison had to place their employees. They literally could not find an empty office building to house the new people needed to staff up the systems area and the operations areas that were needed by the company's projects. Nuclear Santa Nofri nuclear plant was under construction and so on. So the IT invitation was help us rethink our organization so that we deal with this problem of we're trying to deal with a growing workload by adding staff. The more people we add, the slower the project work is and the higher the turnover of the people. And the IT organization gave us an opportunity and by us at that point. I then brought Katie in, Dr. Burke in as an advisor to look and see if what we had here was not just a matter of people problems. Leadership, the poor leadership, for example, that demotivated workers and they left because they were frustrated. And whether, in fact, there was an organizational problem going on, something happening in the way work was designed and the way they were structured, that would be at the root of these issues of poor project performance, high turnover, misallocation of resources, et cetera. So we formed a team. I brought Katie Burke in. We began to hold some intentional discussions within the IT executive group, and at that point, seriously invested in learning and extending. We did a number of organization analyses involving careful, sort of industrial psychology based job interviewing and documenting of the tasks involved in a number of the key career job families, in IT development, operations, maintenance, network management systems, admin, et cetera. What we came to the conclusion was, is that the IT organization had literally all of the qualities of a non levels of work based HR practices. They paid people on the basis of job title. They paid people with job titles. They were driven by the corporate HR. Hey, point and factor system. There was all sorts of restructuring project teams in order to get more and more job evaluation points. So you pump the salary up because you wanted a bigger salary to hire more people. There was meeting madness in the sense that the coordination and clarity of tasking was so poor that the workforce was spending an enormous amount of time on meetings. And we found out that there were all sorts of little things that were adding up to big use. The example I used the most, and Jerry, I'm going to ask you specifically on this one. Ken, I think I would know what your answer would be, but Jerry, do you go back in it world? I think you were with IBM for a long time. You're familiar with the old world of green screen computing and JCL and all that.

Speaker D Am.

Dan Smith Oh, yes. We've come a long ways. I take pride in a few gray hairs and some wrinkles. These are hardwood lessons.

Speaker D Whatever color it is, as long as it stays.

Dan Smith:  Yes, I hear you. We had a project team go on in one case by project team. We also then involved ourselves by our we, my team, my staff, myself and our consultants in figuring out how to assemble the right teams of managers to do the analysis in their work, and that's sort of off to the side. It's one of the lessons learned about how to do organization structure analysis. But we found one case, for example, somebody in the customer service application arena had put in a JCL control that requested two copies of customer bills to be printed, and that one copy would be used for troubleshooting and debugging purposes. And the way that worked is when bills were printed, that was a six and a half day job. It took six and a half days, 24 hours days, in order to print a full set of bills for the customers. And the next week, they had to start over at Sunday at noon, Sunday at noon in order to get the next week's bills in. If there was any failure, they simply could not bill the customers. They were total maxed out in capacity for printing and systems work. And the billing would roll off the printers and be boxed and palletized, and forklifts would literally come and get the papers and send one copy of the bills off to the mailing center to be stuffed and mailed, and the other, they would drive to a separate dock and put on the dock to be picked up by the trash company and shredded. And we asked, what the hell's going on? And it turned out that this request for the second copy had been put in place a couple of years before and never canceled. And no one in the operations room ever thought to ask, what's going on. But they just threw away half the copies of the bills. Remember, this is six and a half days of printing they threw away each week. And it ran to 400,000, something like that. 400,000 a year in paper costs. All that was necessary was to track down the software managers who were in charge of the customer system and ask them, do you need two copies? Well, they had not been receiving two copies since they had started to throw away the unnecessary ones. So they never thought there was a problem, and they went in and fixed it overnight. But it had gone on for 18 months, or between 18 months and two years. We never could find the original start, but that was the case. What that told us was there's something going on in the fundamentals of organization structure and so on. And we at that time, began to redefine roles and start to actually redefine. The example of that much waste was that there was just one of dozens of things we found out about. Operational details, system quality. All sorts of problems were happening on the people side. The organization, of course, ran 24 7365 on the swing shift and night shift in the operations arena. They created a job called a payroll called a shift supervisor, whose job was to collect payroll tickets. But because they gave them the job title of supervisor, all of the employees we interviewed on the swingshift and the graveyard identified as their manager. This job called shift supervisor, when in fact all of the executives and management team held the director of operations responsible to be the manager of all three shifts. We had two thirds of the operations personnel in this top IBM company not knowing who their manager was, who literally did not know the correct name of their manager. And the manager never visited the swing shift and night shift because their job was defined as on prime corporate hours. These were the kinds of problems that our approach from an organization structure put in place. And out of it came intentional redesign of the organization. And that generated then brand new definitions, comprehensive definitions of all the jobs, from the head of it down to the level of the forklift driver or the programmer coder. We worked out job paths that were based on levels of work and did not have extra layering, et cetera, for all the systems development areas, all the operations areas, all of the managers. I'm trying to think if we missed anybody. We actually didn't. We covered all of the jobs and then instituted restructuring activities based on the definitions of the various job roles by level of work. And we introduced also a careful analysis of the functional need for a role and identified jobs that would be high value adding if they were created and staffed right, but who had not previously been identified as even work that needed to be done. This was what I've come to call missing work. When the full plan of work was laid out, what we'd done is in essence redefined in levels of work terms, the work of it. And we identified four different layers or types of managerial leadership role. But we also defined individual contributor work at all the work levels, up to the level of subordinate to the chief it officer, the CIO. And we created dual career paths. At 1.1 survey of our middle managers, the group of about 100 or so, what we would call director level managers, project directors, and application team leaders, we interviewed 100 and asked them if you had a chance to work as an individual contributor rather than a manager, but would still be able to be involved in key decisions and system planning and project teamwork and so on, which would you prefer doing? And two thirds of them said, I really have no desire to be a manager. I just want to be involved in the key issues, key project key decisions that affect my team and affect my work. What they were saying was that we don't add value as a manager, but we have work to do at the higher level, at the level of management, higher level, what we would call today work levels three and work levels four. The redesign of all the jobs resulted in a restructuring of the department. We took out two to four layers, identified with sharp definition levels of work 5432 and one roles, and then instituted the restructuring to implement that. In doing so, that put us in the process then, where each level of management or each manager was involved in the development and talent identification and talent development of the appropriate professional pool, one level below the level of their own direct reports, this skip level development principle was able to be applied. The bottom line was we got between three and six, three and $7 million a year in concrete budget savings. Turnover was down to about 6%, which in the utility is really high because normal utilities were sub 2%. But for an IT organization by the mid seventy s, what we wound up with was a turnover that was really not much higher than utility as a whole. And project productivity went up. And I used to put it we got rid of two to four layers of management and increased the amount of managerial leadership that was present and in place. And the results were pretty dramatic. The proof of the pudding was in the budgets and in all those concrete terms. You asked about the work of the IT of the CIO. It was that project work and transforming that has guided the analyses I've done subsequently on levels of work in the IT field. And when we base those designs on levels of work analyses, I think we wind up with significantly more capable organizations, fewer layers, more sharply defined roles, much lower likelihood of missing work, and a culture and a structure that allows new roles to be put in place when they're needed. So when issues like big data come along or quality, or I'm going to say agile development, almost all well go back a few years, the year 2000 problem, virtually all the project work that came down the pipeline was able to be filtered and assigned within the template and framework of thinking in terms of levels of work analysis with, I think, generally accepted good results. My work then at the company got pulled away. I wound up being involved in more corporate work and I was called on by other departments to come and take a look and see what they were doing. So I looked at from corporate governance department, our nuclear training group. I did projects where we looked at operations and maintenance planning and the power plants. The tools that we developed for it were found to be transferable and very productive. In recognizing, identifying and recognizing problem points in a non requisite setting. I'm speaking a lot.

Speaker C But before you go on to these other applications, do you have a rough idea of what happened to the headcount overall in it from before and after that major restructuring?

Dan Smith:   Yeah, what happened was the headcount stayed the same, but they stopped growing. And so most of the San and Oprah nuclear power plant growth and systems work, most of the restructuring that came with utility deregulation by the late eighty s, all of that was done with no further growth in it. So the savings, when you looked at the curve of the staffing, but it just simply flattened out. And with low turnover, what happened was you had a very stable and more productive workforce.

Speaker C I may have missed it. What was the approximate level of the IT force at that time?

Dan Smith:   We started like 1050 and wound up at about 800 and 8880, but that 880, we're handling a dramatically bigger and more complex technical environment. And during that same period, the IT department, for example, inherited and integrated the telephony. Telephony, different people say it different ways. Utilities run their own telephone systems. They have since the 19 teens when they needed communication systems to connect substations and so on, across all the high tension lines. And most of the telephone, the core utility grid is actually phone lines that are run by utilities that run their SCADA remote control technology and are also a phone company, an internal phone system, all of that was rolled into it at Edison by the late eighty s. And that allowed the modernization of the whole IP networking. So our headcount modestly down, workload up, and we stopped this out of control expansion. And the principle of getting work done by hiring more people, it sounded counterproductive. We got more leadership by having fewer managers. We got more productivity by having fewer people trying to produce things. And we got more innovation by identifying people who had previously been buried low in the organization and empowering them as high level individual contributors. And those were big, powerful lessons. And they've been borne out in other work in it as we've gone along in the systems arena. One of the best project examples, the company purchased a software application for, gosh, I'll forget what it was, 600,000 to manage stock ownership, to just handle the stock transactions of people that bought and sold the company's stock, and working with the markets, they then spent, I'm going to say, half. It was either a $600,000 purchase with a $300,000 investment, or 400,000 with a 200. You got the idea. Investment, disabling the functions of the new system so that it would perform and act exactly like the old, right down to the reformatting of reports, so that it would appear as if there was no new system to those who were using it. When I saw that, and when the analysis team that we formed got to talking with the people that were doing it, that was determined the decision to disable new capabilities and recode the system so that it would duplicate what's already there, was made by a low level project staff who were project application people, who were asking the end users. They talked to the clerical staff in the department that used the system, what do you want? And they were told, we want it to do just what it's doing now. And without the right level of contextual leadership and overall system conceptualization, the IT team just went and did it. That one, fixing that problem won that executive, the corporate secretary an extra bonus. She didn't share it with me and I was pissed about that, but she still got it. Those kinds of problems were all over the place, and that's what we were fixing. I would extend if we move to question two, and again with a constant mindset of your question, Jerry, of give me evidence, show me how it's better before, after. I think that's a guiding principle that would underlie our whole thinking here. Question two is asking how have you used them? Et cetera. I would make the point that what was happening at Edison and has extended in my other work, leaving Edison to work nationally on projects for me, happened in the late eighty s. I subsequently worked independently as an advisor for a number of companies. Was an advisor for Edison. They were outsourced to eds for a short time that went to hell in a handbasket. And then they reconstructed department not long after that. So they've had real struggles in the deregulation, et cetera. One of the lessons was why didn't the changes we make last? And so that way I would flag as a point we want to make sure we come back at Ken is what can we learn about the way we made changes that were dramatically productive, and yet they didn't last. So what was the barrier? My own work extended into other heavy manufacturing. I was asked to do a project looking at the IT structure for an aluminum rolling mill operation, heavy manufacturing in the midwest. They had a situation, this was at Commonwealth Industries in Louisville, Kentucky. They had a situation where their IT and HR functions co reported to the same vice president. And the question was, do you think this is a good idea? So the analysis that I made was a level of work analysis and a functional analysis of their IT function. And so much smaller operation in number of people, but every single one of the same functions was required. This is about a billion dollar business of about 1100 employees. And in that organization, the conclusion was pretty straightforward. HR and it are really different. They're sister functions, but they are really different. And one executive really cannot do both jobs. Each of those jobs requires capability. Not the capability, but requires special knowledge and the growth of familiarity with it, et cetera. And HR is the same with the regulatory changes and what's happening in the HR arena, particularly in a us steel workers setting where it's heavily unionized. So I recommended they in fact divide those functions and put in place a VPHR and VPIT, or CIO. And they did that, asked me to be that CIO. And I accepted that role and was there for a couple of years as we implemented the split and the transformation, and then moved to a more permanent IO setting with someone who wanted to do specifically the work of IO operations. The point I wanted to raise with that one, Ken especially, was that's an example of raising the level of a function by recognizing the proper level of work at which the function needs to be placed in terms of its leader as HR. And it reported to one executive, and there was no dedicated executive for it. It functionally operated as a work level three operating unit, but when created and recognized that it needs to be led at and positioned at work level four, one of the operational divisions of the company, functional divisions of the company. Then it became a true peer. Functional operations involved in the operate in the manufacturing, and you could that were needed to go forward. So that experience was an experience not just in fixing poorly designed problems, but in actually getting it position, quote at right level of work. And that reinforced, for me, it reinforced a confidence that levels of work based models of organization design allow us to not only design effective work systems, but to position functions within an enterprise for effective interdependency, so that your IT HR other support service roles effectively work as peers to the operational spine, roles that too often are seen as senior to the support roles, and therefore you wind up with too low a level person trying to get a job done for a key functional group, and it just doesn't work well.

Speaker D If I could interject something, that's what I'm struggling with. Exactly what you just mentioned, Ken, we know that problem about where it fits and how it fits and where it should fit. What I'm still struggling is why do I need to go through the entire model that you have to be able to understand how we ought to change where it fits in the organization. Again, I do this kind of a thing and again, we know the problems that exist in where it typically or often reports. We know the places that are more effective or less effective. We can go in and reconcile how it could be improved relatively quickly without going through that entire model. Now that the model might not be able to find some other problems or opportunities to address, just like any good consulting engagement might do. But what I struggle with is I don't know why I need to go through the rigor that you have to be able to go in and make a recommendation to a client or if I'm within the company to make a recommendation to my CEO.

Dan Smith:   My best answer I can give to that is there's a difference between knowing that your it function ought to be positioned and empowered, authorized, budgeted, resourced to function as a complementary peer to your operational spot. That's more technical language, but it basically says, we know our need to be positioned at a level to manufacturing. Now that's a general statement, but when you take it to the next level of specifically, then what people should we hire? What is the difference between candidate a and candidate b when we're considering to be the head of that function? What do we mean really the level? Very often in my experience, people make the first decision, recognizing for strategy reasons and just general logic that they need to be positioned, quote as equals. But when you press and say, what do you mean as equals? Without levels of work as a template and levels of work as an analytic tool, one is forced to fall back to old. Traditional, not old, that's not the right word to traditional competency model based HR principles. And so we pick people on the basis of past salary grades. We pick people on the basis of their personality, harmony. All of the things that early on I learned were relevant but not determinative. And if it was so easy to do, why would it have been done so poorly for so long? My response would be to organizations. Think of all of the places where you've known that was the thing to do and tried to do it, and it didn't turn out right. What is it that you're missing that causes then the action implementation to be so unsuccessful so frequently?

Speaker D Your points are good, but the answer is relatively straightforward and we know it. The answer is typically it's cultural and change type of things that even if you go through a more rigorous type of an assessment, doesn't necessitate that they're going to take the recommendations any more sincerely or concretely or seriously than if we came and made the recommendation without going through the assessment. But what I'm hearing you say, it is not necessarily as important a vehicle for organization structure as it is a hiring vehicle or solution.

Dan Smith:   No, that would be an incorrect. That's a great question. And if I was communicating that, I would have communicated incorrectly. To me. The question is, what is the most important leg on a three legged stool? The question itself is a meaningless question. I think that this fundamental design of a job, the structuring of the organizational role, accountabilities their relationships with each other and the authorities, and tasking that's suspected of a role, is a coincidence priority with the selection of the person that's put into that role. And there is a third leg on the stool which is equally important and profoundly integrated, and that is the leadership systems that reinforce and implement that person in that role. In other words, performance management and pay and job titling. What I found and what happened at Edison was we knew the jobs we needed and we could define them in terms of the level of complexity of the tasking and the relative differential value add. Each role should apply. Then we went to HR, and HR said, this makes no sense in our current system. We said, we don't need nine levels of job titles. We just want four job titles. In one particular meeting, I recall. And the HR people said, we can't give that to you because you would be out of line and non compatible with our entire corporate HR system. How do we then? And at that point, it became very apparent that the fundamentals of the HR system, of compensation, job evaluation, et cetera, those things I think, Jerry, you were thinking of in terms of cultural dynamics, the enforcement, those things are.

Speaker D No, I'm not. Absolutely not. In culture, I'm talking about, again, looking at it from an IT perspective, that a lot of other non it executives culturally have difficult, like anybody else, have difficulty with change. And if, in fact, the CIO had traditionally been reporting to the CFO, for example, they'll have a difficult time accepting the fact that the CIO should now be a peer and report to the CEO.

Dan Smith:   There we go. Great. Let's take that one point, and I guess you and I should be bookends on the same conversation. The big value I've found in a comprehensive, explicit, testable set of principles as expressed in levels of work based approaches and levels of work based theory, is that you can give a reason to the client for why the change is being proposed and give them an explanation for why it is it's necessary to do a certain thing, and what to expect. If they don't do it, it can create an opportunity to actually test their thinking. Because you're right about culture. I agree with that completely. The culture is the mindset or the fundamental philosophy. Nobody who's worth a shit ever goes to work for it or it. People are not. They're subordinates. They ought to be part of administration. All that traditional mindset and those philosophies, they're real, but they can't be changed by just pronouncing it. You have to have sensible answers to explain to people why it is that they should be different. And I've not found any more persuasive reason than facts and clear, consistent principles. And these are the best principles I've been able to find.

Speaker D So I'm in sync with you, Dan, and I can come up with those reasons depending on the specific organizational environment and situation and perspective, et cetera. And again, I'm trying to be candid. I still don't see the merit of going through the tool to attain that. And if you've got an example, I know we're still building the one for CIOs, so perhaps I should be more patient and wait to see model that, because it probably is going to be the same kind of thing that I would go through or have gone through in the past with organizations.

Dan Smith:   I found that the processes of change management are dramatically simplified in implementing a requisite. By requisite, I mean effectively designed with work at the right level and the right working relationships between leadership, et cetera. In the enterprise, the processes of change are dramatically simpler because one is not trying to explain why the wrong thing should be sustained when somebody asks, for example, and that's one of the other reasons why doing the process and correctly analyzing it, you're building a readiness to implement, and therefore your changes are actionable. To come in without the analysis, even if it's the correct advice, is less actionable because the client is not ready and prepared to understand why it is the change is necessary. And so when one is asking. For example, I had a client in a utility who I met with. He was an executive VP, EVP in a situation where there clearly was too many levels of executives. And what he was laying out for me was the need. Their biggest corporate problem was a merger. They were anticipating. We talked about it and worked out in confidence a strategy where he would leave his role as executive VP and number two in the company to move to what was an independent contributor direct report to the CEO, ostensibly for, quote, future business development. Well, what nobody could be told was, what was actually going to happen was that person was going to lead the development team to make a run at another company, which they did successfully. Inside the organization. No one knew what the, why it was being made, and so they looked at it, and this EVP was seen as a failure whose career had been destroyed, and he was kicked to the sidelines. For me, that's always been a vivid example. This guy had real balls. He took the assignment and everyone. Then later by later I mean a year and a half realized, oh, that's what was going on. Now I see why XYZ did what he did and his status was restored. But for most managers who don't have that kind of character and that kind of capacity to ask them to give up what is perceived to be high status and big winner for something that is perceived to be, the loss of status and confidence and identity is almost impossible to get to be accepted unless you have good reasons. And I haven't found a place to give it better. I haven't found a better way to give reasons that are persuasive.

Speaker A Thanks for listening to this audio program. If you liked it, why not send a link to a colleague you believe may be interested? For more thought leader audio interviews, visit the society's website   globalro.org.