Cross-functionality is certainly a buzzword of agile. It’s the notion of having all the people and skills needed to do the job, whatever that might be, on one self-organizing team.
Unfortunately, the execution of cross-functionality is often flawed and biased. The main traps we fall into are misunderstanding the value of specialization, hero worship, and not “walking the cross-functional talk” as organizations. Let’s examine each of these pitfalls in the hope that your teams may avoid them.
Misunderstanding the Value of Skill Specialization
Specialization has a reason and a purpose. One of the first questions we ask when meeting someone new is about our job titles and functions. These titles are one of the first glimpses into how we see our identities and how others interpret them, and let’s face it: Identities and perceptions are hard to change. You can’t talk about cross-functionality without talking about functions; we bias ourselves from the very beginning.
When the topic of cross-functionality comes up, the first comment from team members is usually, “I have to be a tester and a developer and be an expert at both?!” This causes an internal upheaval because regardless of our perceptions about our current roles (a developer should be writing unit tests and making sure their code is working, and testers should be writing automated scripts, etc.), we’re often biased against other roles, so we have an identity crisis. When our job responsibilities within our roles may change, we panic.
Roles, by definition, require specialization. We don’t expect developers to handle UX or business analysts to write code. But we should expect that they at least know enough about the discipline to ask questions, follow conversations, and contribute. They must know when they need more expertise on a problem or if it’s one they can solve themselves. That’s where we should start the cross-functionality discussion.
Having cross-functional teams does not mean everyone needs to be generalizing specialists or specializing generalists who know all the things. It means the teams solve problems by utilizing the skills of others and build new skills (and pieces of identity) collectively along the way.
This was readily apparent when I was a developer fresh out of college. I had zero identity related to work, yet there I was in a developer role. I fit into what the team needed me to do. I learned CSS and built my HTML skills. I was responsible for updating the database, so I brushed up on my SQL skills. I dabbled in .NET and jQuery. And of course I had to test my own work as well as that of my coworkers so we could deploy it. I was also the resident expert in process improvement, so when we implemented new systems, I filled in the blanks by working with my teammates to document what was already in their heads while adding my fresh ideas.
Looking back, I didn’t realize at the time how cross-functional that team was and how much I learned from my time there. We had specialization, yes, but everyone was willing to learn new things and help out where necessary.
Hero Worship
Digging further into specialization of skills, we inherently know what we’re good at and what the unique value is that we bring to a team and an organization. However, when we are not willing to learn to become more cross-functional or share our expertise with others, we fall into a trap of hero and skill worship, which becomes a bottleneck or single point of failure.
By not addressing these roadblocks to cross-functionality and redistributing the load, the entire system can never go any faster than its bottlenecks. We often say we would like to address these bottlenecks, but either we do not make the time to cross-train or we perpetuate hero worship through knowledge hoarding.
One organization I worked at had a front-end guru who knew the system inside and out, having written most of it. People would go to him with requests for changes, and he would prioritize based on how much he liked them. If he left, we would be in trouble, because no one else knew the system. That gave him an immense amount of power, and the way he was worshipped was unhealthy. Others weren’t being empowered to advance and learn.
In a different situation, I was discussing the importance of cross-functionality with a group of managers. I talked about development and testing working closer together on the same team, and the reaction I received was, “My developers have more important things to do than test!” If that was not hero worship—misunderstanding of the value of the whole system and general elitism—I don’t know what was.
In that case, testing was the bottleneck because the developers were not held to a high code-quality standard and were consistently introducing defects. The bias of efficiency over effectiveness led to the worship of one function over another. If we can’t see the value of all the parts of the system, we need to examine the system again and determine whether there are pieces that need modification.
Our Organizations Aren’t Cross-functional
The way most organizations are set up is the opposite of cross-functionality. Think of the departments all companies have: human resources, IT, finance, marketing etc. Some of this is done for people management in addition to expertise. I’m not saying to get rid of all departments, but often, politics between departmental boundaries perpetuates silos and competition for resources. This hurts not only the individual employees and teams, but also our customers. If we can’t see a holistic approach to dividing resources and creating appropriate departmental boundaries, chances are customers will feel the disconnect in our products and services.
Instead of a customer-facing value stream, team formation is frequently based on similar skill sets because we think that, from an HR perspective, the manager of a team needs to be an expert in those skills in order to assign and manage work. When teams are empowered to self-organize, they can lean on other team members to help them divide and conquer work instead of an expert engineer promoted to manager doing it for them. This makes managers nervous, though, because then what is their role and identity?
The answer is that managers should focus on helping employees’ personal development toward further cross-functionality in order to get value out faster to our customers. Customers do not think of our departments or components, or even individual features. They think of the whole system and the value it provides when it all works together, so we need to look at our organizations like that, too.
When working for a large retail company, my teams were responsible for the .com site. They were organized by site function, including Search, Browse, Cart, Checkout, and Payment. On more than one occasion, one of the functions wanted to do something new. In order to do that, the user experience, graphical representation, and back-end components had to be changed. Unfortunately, not all teams were on board with these changes or had the capacity within their backlogs.
This led to the Search team trying to go rogue and just do its own thing. Part of the issue was that there was not an overall program-level prioritization of work to help with these disagreements. The other problem was that the teams saw themselves as separate functions that only needed to interact through their APIs to transfer data.
I pointed out that most customers don’t come to the site solely to search for a product without any intent to browse details, see the price, or follow through and eventually make a purchase. The Search team realized their bias and acknowledged that if their experience was disparate, it didn’t matter how cool their new feature was; it didn’t contribute to the overall experience of one value stream to the customer. The value stream crossed the functions of the teams and their backlogs, and therefore the entire product team needed to be cross-functional for the customer to realize the value.
Overcome Your Biases
Cross-functionality is much more than developers and testers working together. It goes against the biases we have of our personal and professional silos. We need to avoid these common traps so we don’t misunderstand the value of specialization, become hero worshippers who contribute to a single-point-of-failure culture, and let organizational politics influence team and product structure to the detriment of the customer value stream.
User Comments
Highest kudos for broaching in very fine fashion a topic IMHO that's covered much less than it needs to be.