Agile talent: How to revamp your people model to enable value through agility

If your industry is changing quickly, your company has to change just as quickly—or faster—to stay ahead.

Recently, we conducted extensive research to understand the impact of agility as a way of organizing how people work together. The results confirmed the benefits of this fast, dynamic, and resilient operating model. Almost half of the organizations we surveyed are looking for ways to capture the benefits of enterprise agility: speed, dynamism, and resilience. We also learned that some organizations have yet to acknowledge agility’s implications for human-resources departments—especially the themes of alignment, motivation, and craftsmanship.

To benefit fully from agility, new people processes are required. We talked to Joe McCollum, a seasoned HR leader who spent seven years as group HR director at Spark New Zealand, to learn how he used the enterprise agility transformation to access agility’s value by revamping his organization's people processes and models.

Joe has held global HR director roles in some of the biggest companies in the world such as PepsiCo, ICI, Misys, EMI, Daily Mail Group, and most recently in Spark. All of these companies were going through significant amounts of change, and Joe found himself at the center of that change.

Joe, thank you very much for joining us, and it’s a great pleasure to have you here. Would you mind sharing why agile is important to you?

Thank you very much. It is great to be here.

My passion for agile came late in my career, at Spark, 1 where we took a company that ten years ago was poorly rated—back in 2012—to become one of the top ten telcos on the planet. During the last three years of that journey, we took Spark through the agile transformation. Since that experience, I’ve tried to help a number of companies on their own agile journeys, always from the HR perspective.

From a career-highlight perspective, this transformation at Spark was one of the biggest and most important things I’ve done. It was daunting at the beginning. It took me a while to really get my head around it, but when I got it, I really got it. I find it amusing when former colleagues at Spark asked me, “Why didn’t we do this sooner? What took us so long to get it? How was it we worked for this company for 20 years, and it’s only now that you’ve decided to go agile? Why didn’t somebody do this ten years ago?” They’re right.

A lot has been said about the impact of agility in organizations. What is your view on what is the key driver of this value?

I would start by saying that agile isn’t for everybody. Remember, it results in a decentralized, team-based, and iterative way of working, and such a way of working isn’t going to suit everybody.

That said, I honestly believe that agile is a real solution to today’s changing world, especially if you happen to be operating in an industry going through a lot of change. The way I think about it is that if your industry is going through a fast rate of change, then to stay ahead, your company has to be changing at the same or a faster rate as the industry; otherwise it falls behind. It’s as simple as that—increase your rate of change or you will fall behind. So you need to find a way to gain significant speed. If done correctly, agile is a fantastic solution, but it’s not for the faint of heart; it does require a lot of work.

In my experience, the value of agile comes out of a significant speeding up of the company, a far greater customer focus than was ever there previously, and a super-duper turbocharging of employee engagement. There isn’t a company I know of that isn’t hunting for at least one or two of those things nowadays.

When you cut through it, making the move to agile means you’re really going to be breaking the company down into self-sufficient, multidisciplinary, multidimensional teams. That’s the very essence of agile. However, it’s not all about structure. There are many barriers that must be removed to allow those teams to really work. Some barriers you don’t quite realize are there, and many other barriers don’t appear as barriers today but do appear as barriers going forward. So if you do move the organization to agile, be prepared to drive through a number of the barriers. Because you only really get the true benefit that lies in agile if you’re prepared to put those to the stake.

I have talked to many organizations interested in the transition to agile, and in the early conversations, the focus is understandably always on the organization’s structure. Having “seen the movie,” and helped many companies in the making of their movie, if I had $100 to spend on agile, I’d put only $10 to $15 against organizational structure. All of the rest I would invest in agile ceremonies and processes, particularly in the people processes. Those people processes that run in the background are where the real action is, and this is how and where you will unleash the power of your people, your talent.

I am intrigued by your comment that agility unleashes the potential of your talent. Can we elaborate on what are the barriers, challenges, and opportunities to do so?

I’ve worked in HR for 40 years, and I hadn’t realized that many of the people processes, either directly or indirectly, are designed around making sure that the hierarchy stays in place, that the hierarchy is safe. This is how career progression is defined, how compensation is determined, and often how people determine their self-worth. All of the people processes are essentially focused on ensuring that people are correctly placed in the hierarchy.

I didn’t believe this when I was in the hierarchical model, but I do now that I’m out of it. Here is why. A hierarchical model puts people into their relevant box. You have to do your job for the person next door, and most of the time you are not in control of the work you do. In agile, you get back control; your voice is listened to, you help shape the work, you help shape the team dynamics. Everybody’s a doer, and you are a lot closer to the action than you are in the traditional hierarchy. As a consequence, employee-engagement scores rise off the scale—people feel a greater commitment to the company.

In agile, you get back control; your voice is listened to, you help shape the work, you help shape the team dynamics. Everybody’s a doer, and you are a lot closer to the action than you are in the traditional hierarchy.

Agile to me is more about running the company horizontally than running it vertically. Therefore, the people processes across a flatter organizational structure, with reduced siloes, require a very different approach to HR to make them work.

The fluidity of people is a core concept in agile thinking, and this idea of fluidity can get lost in the initial thinking around agile. At the end of the day, fluidity is about moving the organization to address problems and opportunities that come up constantly. You want to make sure that the people processes are perfectly tuned to allow people to get to the action quickly, in contrast to being tuned to move people hierarchically through the old traditional hierarchical structure. That’s the core of what I am talking about.

Interesting; that means that the old model doesn’t necessarily have the same energy and power of agile. You mentioned that a new people process is required to enable agile. What did you change at Spark?

Like any other traditional organization, Spark was hierarchical. We decided to shift close to 3,000 people into agile. We realized very early on that a number of the people processes would have to change significantly. We saw that many processes just weren’t going to cut it in the agile world and that we could do a lot better.

It was a bit daunting—it seems an insurmountable task at the outset, full of risk. But very quickly, we realized that this was one of the prime opportunities, in probably the next decade or two, that we would have as a company to reset completely our approach to people. Soon, agile shifted from being a negative, hard-work issue to being a superpositive, aspirational, inspirational resetting of the company. When you make that mental leap, a lot of doors open. We had an opportunity to reset the company, and I would encourage anyone thinking of agile to go down that route and create something which is magnificent.

There are areas in HR that you really need to think through to support the agile journey. So let me talk about a few we addressed.

First, layers. In a traditional hierarchical organization, it is not unusual to see seven, eight, or even nine layers of management. In agile, that effectively goes down to three. It is a radical shift, as middle managers don’t exist in the agile model, but the middle-management function remains, albeit in a different form. The role of middle management absolutely continues to be done, just not any longer by middle managers. Getting that right and managing the transition of the middle managers were two things we deeply thought about.

If you reduce layers from seven-plus down to three, that has a direct impact on career progression. In a hierarchical, multilayered organizational structure, career progression actually isn’t that complex; it is about moving people up every couple of years. However, in a flat, wide, end-to-end agile model, career progression requires a lot of thinking. It has a different level of sophistication, equally uplifting and aspirational. In agile, everyone is a doer, has a hands-on role. So you need to create a career-progression model that knows and respects the doers’ skills and has a degree of complication attached to it.

Sidebar

Compensation, incentives, remuneration change dramatically. Our old world, like many companies, was made up of salary ranges. Most hierarchical organizations have the same mechanisms—for example, salary ranges, plus or minus 20 percent of the median, with a degree of flexibility as to where people sit in those ranges. Certainly, that’s how our old world operated. We moved to something that we call the contribution model, where people are paid fairly for the role they do, so you cut out the small variances that exist along salary ranges [exhibit]. It’s a lot of work, and also scary, for a company to have to shift away from something as essential as a range-driven individual compensation model. Team collaboration, team recognition, and team rewards become more important in agile. You can’t have a situation where you’ve got a squad of ten people, all on a shared mission, but at the end of the year, two or three people on the squad receive an individual incentive while the others don’t. It just isn’t going to work [for more, see sidebar “The contribution model”].

In five steps, the contribution model measures three dimensions of  employees’ skills.
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

Employment agreements and job titles changed as well. In agile, we probably moved 20 or 30 times as many people over the course of the first year as we’d moved in the previous five. Therefore, we had to change the employment agreement to highlight the fact that we would be moving people during the course of the year. In the new model, in a particular year people can probably expect to work in three or four different areas within the company. Doing that in the old hierarchical model required letters to be drawn up—changes to job descriptions and other bureaucratic elements. To support the new flexibility required in agile, we rewrote the employment agreement around the realities of agile and the agile ways of working.

Performance management also has a very different feel in agile because people work in a squad yet belong to a chapter or functional area. Agile is a very fast operating model, and it requires fast, regular feedback. Therefore, how performance feedback is given is very important. A little bit of feedback very frequently is far better than a big lump of feedback irregularly. Traditional performance-management systems are built on the latter—they arrive at very nicely tight performance appraisals every 12 months, and that won’t work in an agile model. Also, you have to go out and hunt to give and receive feedback in the agile model; by this I mean that you have to talk to someone in the chapter or functional area to get a read on the functional skill of the person being evaluated. Then you have to get a perspective on that person’s ability to participate effectively as a member of the team, so this is more complex. Done well, the feedback, and the results, are a lot richer.

Then there’s leadership. One of the terms that gets used is “servant leadership.” Probably the best way of describing it is this: if you are a tribe leader or if you’re holding one of those roles of seniority, your job really is to get the tribe to function, to keep people focused. As part of that, you drive up engagement. So command and control doesn’t work; the agile approach rejects it. Rather, it’s all about how you get people engaged, how you get people collaborating. How do you get the best out of people? How do you create an environment where every voice is heard? I’m often asked, if there were one quality to really look for in an individual, what would you look for every time? Collaboration skills—they are worth their weight in gold in agile. Agile leadership to me is keeping people focused, on point, and reducing the number of distractions; driving up engagement; encouraging people to speak; and making sure every voice gets heard, which requires leaders to raise their listening skills and be far more visible, present. It is about in-the-moment leadership. 2

That is a great story. And it seems that you were finding challenges as you went into the transformations. I guess several people reading this interview are or will be facing similar challenges. What advice would you give them?

Agile is about changing mindsets, recognizing that what’s gotten you to where you are today probably isn’t going to get you to where you’re trying to go. It is a significant change in mindset not only for you as an HR leader but also, I suspect, for your leadership team and for the wider leadership group within the organization.

My advice to any HR leader would be this: first, stay ahead. Agile is a journey; it is quite a complicated journey. It’s got a number of moving parts. I wouldn’t recommend that you go tearing off and try to get all the answers immediately. Pace yourself and just try to keep one answer ahead of the organization. If you set yourself the task of being 100 answers ahead of the organization, you’ve gone too far. I think you’ll have left your organization behind. You have to go through the journey at the same pace, just slightly ahead.

You must deeply understand things as well. Go and talk to other companies, to other HR folk whose companies have gone through agile. There should be no sacred cows. You have an opportunity to reset the company. If I think of the journey that we went through at Spark, almost nothing on the HR side made it through from the old world to the new world untouched. There were no sacred cows. You should ask yourself, “Is this helping or hindering with our agile world?” If anything is hindering, you have no choice but to change it.

Also, storytelling is, I think, one of the most undervalued skills in management today, and agile is a belief-based model. By this I mean you have to believe that the organization, that your company, would operate better under an agile model than it would under a traditional hierarchical model. If you believe that, then you’ve got to sell that notion to the organization, and the way you do that is by storytelling. So figure out who your good storytellers are in your leadership team. We didn’t really understand the value of communication in the early days, but we recognized the importance of good storytelling as we got into the journey. Make it personal. The warmth of the camaraderie that you create in the organization will be driven by the quality of your storytelling.

And you have to be agile to go agile. I have talked to companies that have put together an agile development team, essentially a group of people looking at getting the organization ready to go agile. At these companies, they’ve been thinking about it, they’ve been on that team for two or three years, and they’re likely not to go agile for another two years. So for five years, they are planning to go agile. I think that will be a failure. My advice would be to think of agile as playing a new sport: you can do the work and theory on whiteboards or in a meeting room, but you have to get your people on the field. Agile gives you and the organization permission to get things wrong and to correct quickly and change gears. If you play with the old paradigm—that everything must be watertight and carved in stone before release—you will fail. Agile is about adjusting; it’s about modifying.

Finally, inspiration. You’re about to take your organization into a world where employee engagement is going to go off the scale, where customer focus is going to go off the scale, where you’re going to become twice as fast as you were historically. How good is that? That’s an inspiring goal; I don’t know of a better one. So you have to look at how you can bring the organization along, how you can create a world where people are queuing up and wanting to get there as fast as they can. That’s the trick, and that, for me, is about inspiration.

Thank you, Joe. This is very inspirational. Anything else you would like to say to those reading this article?

Is agile a lot of work? Yes, it’s a lot of work. Is it worth it? Yes, totally. Is there a big upside at the end? There’s a terrific upside at the end. So have the courage to see it through, to stick to the recipe—that would be my advice. All of the work and effort that you put in during the early stages, you will reap enormous benefits from later on, if you do the work properly. So good luck on the journey, and all the best to all who sail on the journey.

Explore a career with us

Related Articles