In the early 2000s, I worked as a country risk credit analyst at a very large bank in Australia. During a performance review, my boss at the time, who was the head of international credit, said to me, “Phil, it’s decision time. Do you want to be a generalist or a specialist in your banking career?"

After thinking about it for a while, I chose generalist—partly because I thought I might get bored doing the same job for the rest of my life, but also partly because I like variety and I like to learn new stuff. I did not realize at the time how profound that decision was. Although for me it was a natural choice, it's not so natural for others.

Flexibility First, Skills Second

In addition to working with clients who are adopting agile delivery, I am also advising a fledgling tech startup that aims to digitally disrupt the global sports coaching industry. Although I'm on board largely to help with a focus on the customer (and what an MVP should mean) I’m also relearning HTML and learning CSS and JavaScript. This is so I can do some basic coding and help build and own some webpages. I don't need to do that; no one asked me, and I wasn't hired based on technical capability. My front-end web design and development skills are currently extremely limited. My last exposure to HTML was an intranet site. I chose to learn new skills so I could own some feature development and content creation and contribute in a more practical and meaningful way, but also just so I could learn new skills.

It's a well-known though rarely followed truism that companies should hire for attitude first and skills second. You can teach skills, but you usually can’t teach flexibility, the desire to learn, and the willingness to add value.

About ten years ago I was working at a different financial services organization, building a complex pricing and risk-based capital calculation tool for the global corporate and institutional banking team. It was the company's first large scale crack at an agile software development lifecycle, and we were coming close to the first "real" production release. At that stage, with the pressure on, everyone became a dev team member. Those who couldn't code wrote and executed tests and conducted exploratory testing.

Even though I was the project manager, I dug in and wrote user stories and acceptance criteria, wrote and executed tests, workshopped the product with the customer, and found other things to do to provide value to the team. (I was, however, banned from touching any code—and rightfully so! One's gotta know one's limitations.) Where we identified process bottlenecks, we closed them by asking people to be flexible—in short, to be generalists. We moved fast and delivered early, with quality and under budget, even though for most of us, agile was newfangled thinking. The project was so successful that it became a launching pad for broader agile adoption in the company, created the base set of agile standards and practices, and became a Microsoft case study.

Agile Environments Encourage Learning

It’s true we had an amazing team composed of high-performing individuals who also jelled as a group around an outcome. And we had the necessary project characteristics for success: a clear mission and project objectives, decentralized control, a collocated team, and strong and embedded business support from day one. But I think it was just as critical to our success that we had flexibility in task adoption.

Many organizations create or let evolve systems that deliver work in a manner that tries to stifle flexibility by optimizing for cost in traditional ITIL-based silos. When the pressure is on, they impose more governance, more controls, and a “there’s no time for improvement because we are too busy” way of thinking. But to learn, you need free capacity. You need drive and motivation. You need encouragement. And most of all, you need the environment around you to let you learn!

Agile and its incarnations, such as Extreme Programming, Crystal, Scrum, and so forth, look to create cross-functional teams. This allows you to build flexibility in, so when obstacles arise, the pressure is on to release, or people are away or unwell, you don't encounter delay. By eliminating key-person dependency and risk, you can continue to deliver on time and meet your goals. The focus on generalization over specialization lends itself to this way of thinking.

Investing in Cross-Functional Teams

My first career out of high school was in the Australian army. As in all military units, investing in training to become a cross-functional, high-performing team is essential to your survival. In a small, tight-knit military unit, there is really no place for people who want to remain single-skill specialists. Yes, you have a core role, but you learn to become a generalist by necessity. As W. Edwards Deming said, “Learning is not compulsory ... neither is survival.” Everything the army does is geared toward learning fast—for survival!

Agility implies speed and nimbleness, which, in my view, requires people to be “T-shaped”—to have a few key skills that got them hired into the team, but then to learn the basics of other roles. Recently I’ve also been advocating a “Tetris model,” where people have depth in one skill and breadth in others, and over time we fill in other gaps so there are multiple people who can do the same job. We build out redundancy. This requires people with the attitude that learning new skills is just as vital as being great at what you already know.

This philosophy often goes against the traditional emphasis on specialization and optimization you find in most large companies. But encouraging learning new skills and expanding outside core responsibilities promotes flow over resource efficiency, helps cover gaps in time of crisis, and lets you build a team that can deliver continually at a sustainable pace.

You can't do that with a team of specialists. Long live the generalists!