CIO Speaks – Episode 7: A Conversation with Joanna Young of JCYCIO.com

Guest

Joanna has held CIO and CFO roles in the private and public sector in insurance, healthcare, financial services and higher education. She helps organizations solve big problems such as Agile transformation, Lean management, IT strategy, organizational change management, product selection and large program management. She’s known for her obsession with authentic leadership, digital transformation, customer delight and talent management. She participates often in social media; #CIOchat, #trueleadership, #voiceofthecustomer, #WomenInTech, #PeopleInTech are common hashtags.

In her spare time, she’s with kayaking, running, writing, hiking or sitting on the beach watching the waves roll in.

Transcript

Steve Ginsberg: Hi, I’m Steve Ginsberg. My guest today is Joanna Young, an experienced C-Suite exec with deep experience providing digital leadership and guidance to executives, teams and individuals. In this episode we’ll hear Joanna’s insights, specifically, in organizational efficiency and culture.

Hi, Joanna, thanks for joining me today.

Joanna Young: Great to be here.

You've been working with a lot of organizations. You want to tell us a little bit [about] what you're working on currently?

Yeah, sure, so I'm working with several organizations on large, complex programs. Most of them have some aspect of Agile transformation and also related to moving from legacy architectures and applications to cloud or hybrid or hosted architectures.

That's great. I wanted to talk a little bit about project management and program management. In your view, what do the project management methodologies bring to the table?

Well when I think about project management today, I think rather broadly all the way from, if you will, more than one traditional PNP-type of methodologies to the more agile, lean types of methodologies that are being deployed. I think what they bring to the table is really these days, the ability to create a minimum viable construct that is going to deliver value as quickly as possible. I think if people are thinking about project management, whether it's agile or traditional waterfall, that way that it needs to be the most lightweight approach possible to get the team or teams to the point that they're delivering quickly and accurately, then everybody will be a lot better off. Project management is not for the project managers; it's not for managers; it's not for leadership. It's for the teams. It's to support the teams.

Yeah, I like your emphasis on ‘lightweight’ having come from waterfall shops and then moved into Agile. It certainly seems like for a lot of projects, it's a better way to go. How do you feel about communicating to folks–like you said, it's not for project managers only; that's not the goal–about bringing in the partners that you're working with on projects into these methodologies?

Well, though I think the hardest thing for organizations to get their heads around is that these methodologies are, again, not for leaders. They're not for the managers; they're not for the project managers. They're for the teams, and really as I'm bringing different stakeholders together, really the biggest thing is change management, getting people to think differently about how this should be supporting delivery and supporting delivery faster and faster and with higher and higher degrees of quality. A good example is that we're used to—and when I was a CIO some years back—I was used to getting that weekly or monthly or quarterly red/yellow/green stoplight [about] what's going on with all of the projects.

It's things like that–people's expectations about a lot of the effort going into the plans and the statusing–people need to realize that that is of lower value than the actual delivery, and really change their minds about what they're looking for, if you will, in terms of metrics and critical success factors in the projects. For example, a team that's firing on all cylinders and delivering more faster and faster to ever happier customers, whether those customers are internal or external, that's the sort of thing these people should be looking for and thinking about, not stoplight reports.

Right, it's the result, not the reporting.

Right, but still there's so much focus on reporting. Then the other thing I find is that people still get extremely–feel a little wrapped around the axle about resource assignments. One of the things I'm often dealing with in terms of change management is the concept that one of the negative aspects of an organization is the amount of time they spend slicing and dicing people amongst projects. That's non-value added time and wasted time. Moving people away from that slicing and dicing and focusing on fully resourcing the teams on the projects that are of the highest priority [is the better approach].

I saw you've done some nice writing on resourcing and that the planning doesn't necessarily produce any more resources and that once you commit, organizations should commit to resourcing properly those priority projects.

Exactly. I mean, I'm working on real-time, real-life projects where... I think it's very obvious but everybody is coming from a different place, so just because I think it's obvious doesn't mean other people do. We're seeing teams that are producing incredible amounts of value in two-week sprints most usually. Then other teams that aren't and are really struggling to get any sort of velocity or demonstrably higher quality and the largest differentiator between teams in both of those spectrums is that the fully resourced team with the developers, with the product owners, with the BAs and the QA function. Fully resourced teams are just simply so much better positioned than the teams that are not fully resourced and have people sliced and diced between projects, [and] are just simply not going to produce.

I think it's harder for some organizations to get out of that mindset than others, so just understanding where organizations are standing, going to where they're standing, trying to help them move forward at a reasonable speed to a better place, if you will.

How do you advise that organizations should balance the ‘always on’ dynamic nature of business? For example, a year or a quarter might be well-planned at first and then depending on how dynamic the business is, there are often new asks coming in.

Yeah, so my thinking these days, what I believe works best for most organizations, is that they should be planning extremely high-level for maybe, let's call it 12 to 18 months, and then in the 6 to 9 month level or 6 to 12 month level, maybe at a mid-level of planning, and then really only detailed level of planning in what I would call a quarter or two, 3 to 6 months. Then of course when you're talking about these newer agile or lean constructs, you're even getting to a more granular level of detail with backlog refinement and assigning things to sprints and what have you. When I see an organization who's still trying to plan in that beyond 12 to 18 months, like these 2, 3, 5-year horizons and they're spending a lot of time on that, that usually is what I call a leading indicator of perhaps they're not focused appropriately on the right things.

That makes a lot of sense. In you view, does the planning tools themselves matter much, or is it as long as an organization is comfortable with the tools, they seem similar or do you feel there's a vast difference in terms of what can be gained there?

I don't think the top tools–we all know who they are, Microsoft Teams or a best-in-class suite of products. I don't think, if you will, top-tiered tools are a ton of difference. It's like anything else; it's all about the process, the culture. Are people in the right roles at the right times? Does leadership have the right mindset? Are they supporting teams appropriately? Those things are far, far more important. That being said, a badly implemented tool is going to impede that. I more often look to okay, what are the tools you're using and are they helping you or are they impeding you? If they're helping them, let's put the tool question aside and focus on other things. If I'm seeing some signs that the tools are impediments, then we might put that near the top in terms of things to address.

Sure. What about the human element? For example, you've written about hubris and humility. How should IT organizations view those and the other top qualities of the people on the teams?

Well, I think servant leadership is definitely key. Nobody is getting work–very few people, I guess, are getting work done themselves. They're getting work done with and through other people, and that's particularly acute for leaders. One of the leading indicators or lead lagging indicators of success that I see are organizations where leaders truly care more about the teams than themselves, and that tends to show up, if you will, in the full life cycle of talent from the attention leaders pay to the quality of the hiring and the onboarding process all the way through, the career building, whether it’s compensations or promotions or giving people different valuable experiences; all the way really to latter stage career and making sure people at all stages of their career are positioned appropriately to contribute.

Leaders who realize the importance of talent and their role in supporting that talent, those people are very valuable and organizations who are doing well–and you can even see this in organizations at the top of the leaderboard. Organizations who pay attention to that, and who value leaders who pay attention to that, tend to do better than others. This is a topic, as you can tell, that I’m pretty passionate about because I think we’ve all seen very sad examples of leaders who have not had this approach and attitude, and what’s happened to some of those organizations.

How does that manifest in your view in terms of communication specifically? What leader style do you prefer in that regard, both what’s effective and what you think is best for all of the constituencies?

I think you want to look for leaders that first of all, have great communication skills and that doesn’t mean that they have to be massive extroverts or anything like that. They are people who are able to very quickly and expertly say, “Okay, this is the meeting. This is the situation. This is the conversation,” and be able to adjust to the audience. I mean, when you’re a leader, if you’re in the C-suite or in a VP or senior director type role, you got to communicate [with] people all the way to boards, potentially external customers depending on your role, all the way down to individual contributors. There’s a lot that goes into that, and it’s critically important. What I think is important about leaders when you’re thinking more about their organizations is that–I’m going to tell a little anecdote.

I was listening to someone speak not that long ago, and it’s someone who manages... the CIO of a mid-sized company, and supply chain is critically important to this enterprise. They were talking about the fact that they had something I believe, that they called the ‘truck driver test.’ If they were able to walk in to, if you will, one of their locations and say to a truck driver, “Do you know what’s going on with this and such?” If that person was able to say, “Oh, yeah. I’ve heard about that,” and that’s important because–or that impacts the company because–and if they were able to articulate that, then that CEO was like, “Okay, I’m doing my job and the people in between me and this truck driver are most likely doing their job as well.” I thought that was just such a super anecdote because it’s so true.

If leaders are able to foster either through their own words and actions, as well as those who work for them and around them, the types of words and actions so that you can get that level of engagement and understanding at the most far-flung edges of the organizations, you’re most likely doing something right. Also, I thought it was cool that here’s someone who’s the CEO, and he’s realizing it’s important to engage and talk to someone who’s at the edge of the organization, if you will.

It’s like QA or monitoring for the quality of the process as well.

Yeah, and there’s a quantitative and a qualitative aspect to this, right? It’s art and it’s science. As leaders we have to know what the right metrics to look at [are]. You can have thousands of metrics, but if most of them aren’t the right ones, you’re wasting a lot of time and energy in the producing of them. Then there’s this qualitative aspect that there’s a lot of art too, and I think CIOs and CEOs and CFOs, they should be looking for the equivalent of the “truck drivers” in their organization including communication with those folks and their quality assessment of how things are going.

I think it’s a great point on the effectiveness of the metrics. In your view, what makes a good KPI?

A good KPI is one that is closest to how the actual customers of your products are consuming, perceiving, net promoting your products. Those are the KPIs we should all be caring most about. Those can range from the financial, revenue numbersthat [are] obviously going to tell you something about the consumption and the perception of your products. But again, there’s metrics about how fast are new desirable features being added and that gets to things like velocity and quality.

People need to figure out what are the KPIs that are really closest to the customer, and you need to make sure that everybody in the organization understands what those KPIs are; how they relate to their particular role and job. Also, I think what’s particularly important, maybe more so for the leaders and certainly the people involved in the metrics and analytics themselves, is the source of those metrics.

If I had a nickel for every meeting or interaction I’ve been in where somebody has said, “Oh thus and so metric is at 75%,” and you end up having a lengthy, sometimes difficult conversation on “Well, I don’t believe that number and what’s the source of that data and what’s the timeframe of the data?” The amount of time that we spiral into conversations about the validity of certain metrics points out the importance of understanding the source of the data and making sure that people understand this is the source we’re using, this is the formula we’re using, and that’s what we’re looking at. We’re not going to debate these things. We may have healthy conversations about altering something about that at periodic intervals, but we’re not going to sit in rooms and argue about these things once the sources and the formulas are set up.

You’ve spent a lot of time talking about delivering value and delivering it quickly. Where are you on the concept of ‘fail fast’?

I’m high on the concept of fail fast as long as leaders understand what that means: the fail fast and the ‘learn fast’ and the role that they play. Nothing will kill the benefits of fail fast sooner than any public or even semi-public wrist slapping for somebody who makes a mistake. We’re not talking about deliberate mistakes or mistakes that are repeated over and over out of carelessness or the inability to collaborate effectively. Talking about things like, ‘hey, we learned to prioritize this feature and this application and what goes into delivering it’ and maybe the feature doesn’t end up being that popular with the end customers. Okay, well, there’s a lot of learning there. Why wasn’t it popular? Why did we think it was going to be popular? What is really the thing that they want and let’s get on that right away. If leaders are having those conversations when something doesn’t go quite right, then that’s good.

Even in dire situations where maybe there’s a bad outage or whatever, if a leader comes in and is like, “Hey, let’s first focus on get[ting] this resolved,” but then after that, having good constructive conversations about what’s happened. What can we learn from it? How can we get better? The value of that again, positive servant leadership is great, but if people are afraid to speak up, if they’re paranoid that they haven’t made the right choice about the way to deliver a feature, then that’s just going to shut things down and slow velocity, impede quality, and you’re probably going to have a problem with your talent too because people these days really don’t want to stay in organizations that aren’t failing fast in a positive way.

For product organizations, understanding who their customer is should be somewhat straightforward. I mean, there’s work that should be done there of course to refine. For CIO organizations, I know internally, it can be a struggle sometimes to even decide who are the customers, and how they should be prioritized.

How do you advise the CIO especially in the idea of: should they also be considering the end customer of the organization as a whole? How do you advise organizations to go about creating a proper priority around all of that?

Right. Obviously, every organization is different so it tends to be, if you will, an ‘of one.’ How I would advise CIOs is [tell them to] look at your portfolio of products and services and make sure you understand who the customers of those things are and make sure you understand the layers of customers, right? To your point, it can be a bit opaque or murky.

Let’s take something fairly common like the applications that support the various human resources processes. Who’s the customer of that? Yeah, it’s the human resources department. It’s the chief human resources officer or whoever it might be in a similar position, but it’s also the employees themselves, right? Is the HR application the one that’s used for employee add, move, change type of thing? Is that creating friction in the organization so that employees feel dragged down by things that they might have to do related to that system, or is it enabling the organization? How does that manifest itself with the individual employees themselves, managers and other leaders in the hierarchy? What does all that mean?

That can be a difficult–even that can be difficult to tease out. And sometimes the HR department can really see we’re the customers, and we’re the conduit, and you need to be working solely with us. Then there are other organizations where HR is what I would say more evolved where they’re [thinking/saying] ‘Okay, we understand that it’s not all about us and it’s really about the employee experience. While we’re the stewards or the product owners, if you will, we understand that it’s important to get actual employee stakeholders involved outside of the HR department on things like onboarding, and how the performance management process works.’

Yeah, certainly a lot to balance there. With that in mind, how do you advise organizations to seek consensus when you have cross-organizational projects in which there are stakeholders throughout or are at least in different parts of the enterprise?

This again is where every organization is very different and ‘of one’ is because consensus does not mean the same thing in all organizations. There are some organizations that they are extremely hierarchical—maybe almost akin maybe to the military in command and in control, and there is a few people at the top who make the decisions. That’s all the consensus that’s going to happen, and then there are other organizations that are very democratic. For example, academic institutions can be a lot like this, and they want to get wide swaths of agreement before proceeding on things, and then there’s everything in between. When I was talking to CIOs, it’s like, “Okay, you need to understand,” particularly new CIOs, “you need to understand what does consensus even mean in your organization, and make sure that you’re talking to existing people in the organization who have been around for a while who can talk to you about that.”

There’s pros and cons at both ends of the spectrum. With something that’s very command and control, maybe decisions and prioritizations [are] made quickly, but maybe you’re only relying on a few people or maybe those few people aren’t always correct. Whereas if you’re doing a very democratic approach, where there’s wide buckets of folks that need to be consulted and have their feedback incorporated and so on and so forth, that can be very, very time consuming and very slow and you can lose time to market opportunities. Again, I think a theme here is, whether it’s consensus or tools or how you’re doing Agile, how you’re managing people, there’s no ‘one size fits all.’

The CIO really needs to do a lot of thinking and exploring and be very curious about how all those things work in an organization, both within the IT organization and outside the IT organization and figure out what of those things are contributing to velocity and equality and delivery, and which of those things are creating barrier conditions that they need to figure out. I'd do a plus one then is that, these days, since most CIOs and their organizations are very dependent on vendors as we move more things to the cloud, that yeah, it’s a good idea to understand some cultural aspect of the vendors you’re engaging with as well because that can have an impact.

Yeah, quite a lot to balance. I did want to ask you that on the human resources front for IT organizations and for companies as a whole. In addition to salary parity, what would you like to see IT organizations doing to promote women in leadership positions, and also support them strongly in direct contributor positions?

I tend to be a pragmatist, and one thing I will say is that until there’s more women in leadership positions, there won’t be more women in leadership positions. Companies need to be turning that wheel much better than they are. One of the things that has been disturbing to me recently and I’ve been talking to colleagues about is that you’ll hear organizations say, “Well, there’s plenty of women in IT.” I’m like, “Okay, let’s talk about the roles that women have in your organization.” There’s still a tendency–you’ll see women in HR roles or project management roles and not so much in the more technical roles or senior roles or leadership roles. I will freely admit that that’s anecdata, but when I look at studies on these things, that does tend to be what you see.

I think there’s a long game and a short game here. The short game is that you need to be looking at what everybody wants their career trajectory to be, and you need to be looking at the organization and actively saying “What women do I have at various levels of the organization who I need to be reskilling,upskilling, focusing on so I can get to a better place because the data clearly states that the more diverse organizations are, the better off they tend to be. That’s the short game. That’s something that organizations should be actively doing now, and a good chief human resource officer and the like should be able to help organizations with that.

Then the long game that companies need to be doing is they need to be working with schools—even down to the primary and the middle school level on the pipeline. There isn’t going to be some silver bullet in the next few years and all of a sudden, we’re going to have turned the corner in the amount of women graduating from universities with STEM or equivalent degrees. There needs to be a lot of change in our educational system to get a pipeline to a far, far better place.

It’s interesting when people talk to me as a woman, they’re like, “Well, are you doing this because you’re a woman? Why is this a thing for you?” I’ll say, “Well, here’s the reason it’s ‘a thing’ for me, is that everybody is screaming for talent. Everybody needs developers and other technologists and IT security folks, and everything else and there’s a dearth of talent. Why would you not be focusing on the entire set of the population, men and women, and making sure that companies are going to be making iterations towards a better place and having enough talent available?” At the end of the day, it comes down to the math and the types of expertise that’s needed in the 21^st century versus the type of expertise that we have available.

Yeah, absolutely. We may have touched on it already but what would you say are the most valuable things that CIOs and their staff should be working on in 2019?

They should be working on figuring out what’s most important and prioritizing. The problem I see is so pervasive every organization that I talk to is that, they don’t have priorities because they’re prioritizing too much. In my mind, they should be working much more specifically and spending more time on what are really the most important things we need to be working on. It’s not a hundred things and it’s not 50 things. It’s less than ten things. In fact, some would argue that it should only be three or five, and so that’s number one. They have got to get that figured out.

Then the other thing is that everybody–I don’t think this is an exaggeration—everybody is somewhere on the “journey to the cloud” which can mean a lot of different things, and there’s a lot of different bits and pieces to it, but I think that organizations need to be doing a better job of not just figuring out technically where they should be with their portfolios. They need to be changing, if you will, working on changing the DNA of the IT organization and the adjacent parts of a given company or organization to be prepared for what that means.

I mean, just take things like IT service management processes. IT service management processes need to be completely changed when you’re talking about moving to software as a service or storage in the cloud or analytics in the cloud or whatever. What I see a lot happening is, everybody gets enamored of the technology and they start down on this technical journey, but the IT organization is not very well prepared in terms of their processes or their talent and so they struggle. The last thing I’d say about this is that a leading indicator that an organization may not be thinking about cloud in the right way is when the leading question or the only question is, “How much money are we going to save? How many fewer FTEs are we going to need?”

Absolutely.

It certainly is a question that needs to be asked and answered but it’s one among many, many questions. I’ve had people ask me many times, “How much do you think we can save if we go to XYZ cloud-based solution?” I’m like, “Well…,” and I will be very honest to people. I’m like, “I can’t answer that question until we have a lot more conversation and a lot more analysis. Let’s talk about a full suite of questions that might be helpful to be asked and answered with that one among them.”

Yeah, glad to hear you’re focused on that. Some of the work that we’re doing at Gigaom is actually looking at what are the real costs of the various cloud technologies, as I think was implied in your statement. A big part of it is, perhaps as you move to the cloud, you’re going to change the nature of your work, and that might be a fantastic business opportunity that saves no money at all. It may be that you’re just going to do much more than you were doing, and in a lot of cases you will then just have to change the nature of the work, but it’s not about less.

Right, exactly. I mean, the question should be around ‘okay, not what’s the amount of money we should be spending on IT, it’s what delivery and quality and value should we be getting out of our IT investments from–particularly again, IT talent?’ I mean, IT talent tends to be, in most organizations between 60% or 80% of the overall budget. Compensation is huge chunks of the budget. People want to change to these new constructs, but what are they doing about reskilling or upskilling their organization? In my opinion, layoffs are a failure of leadership. Not everybody would probably agree with me, but that’s where... I’d feel pretty strongly about that.

Great. Why don’t we leave it there? I want to thank you quite a bit for this discussion. I think you’ve given a lot of great advice for IT leaders, and thank you for speaking with me.