Articles

Cross-functional teams with high skills

Cross-functional teams with high-skilled people are key to doing concurrent engineering and developing sustainable products.

The interchangeability of roles in these cases is very limited, and it is natural that small silos of teams will develop.

Skilled people today suffer from difficult social acceptance, and their cooperation with less skilled people is the challenge to be faced and overcome.

cross-functional teams

Cross-functional teams with people who have very different skill sets

The development of physical products from high tech to industrial machinery and finally to building construction requires large teams with specialists from very different disciplines.

These people are joined by stakeholders who are often other specialists who are experts in the business or a technical domain.

All these specialists are skilled people who have:

“an intangible but recognizable combination of education, talent, experience, and peer recognition”

(Excerpted from the book in his book “The Death of Expertise: The Campaign Against Established Knowledge and Why it Matters” by Tom Nichols published by Oxford).

As specialists in one or a few disciplines these people are not always used to cooperating continuously with other specialists, as agile teams require.

In this regard, I read a very interesting article written by Emily Webber in info Q “Bridging Silos and Overcoming Collaboration Antipatterns in Multidisciplinary Organisations

The article was very thought-provoking for me, and I was particularly struck by the concern of Emily Webber, who is a consultant following team development, about the fragmentation of work in teams.

  • Fragmentation is represented by the fact that specialists continue, mainly developing product elements that require their specialization at the expense of less cooperation.
  • Added to this is the fact that some skills are so rare that some people work on multiple teams in parallel.
  • In the article, the author points out that these specialized ways of working carry the risk that people will continue to refer more to the leader of their domain (Domain Leader) than to the Product Owner.
  • The additional risk is that silos form within the team.

These are situations that I routinely encounter in physical product development.

The author states that in her experience generalist figures are more willing to cooperate and identifies several antipatterns of cooperation.

While I share the author’s concerns, I have instead gained a very different experience that leads me to different conclusions.

If a product development team involves relatively homogeneous skills, such as those of a soccer team, it is reasonable to expect strong interchangeability with a consequent interchange of roles.

If, on the other hand, a product development team involves highly different skills, such as those of a jazz orchestra, the ‘interchangeability is zero or greatly reduced.

In fact, it is unthinkable that a drummer and a guitarist can play each other’s instrument at a high level. And so too are technical skills from very different disciplines such as mechanical or electronic HW and firmware.

Therefore, it is natural for work to be divided and small team silos to form.

Cross-functional teams and the acceptance of skills

I, on the other hand, am very concerned that specialists with high skills suffer from difficult social acceptance in these days.

I am reading right now the very interesting book by Tom Nichols that I mentioned earlier.

The author describes the drift over the past 20 years in the U.S. whereby a competent person is looked upon with suspicion and equality of rights is exchanged for equality of competence.

The consequence is that some less skilled people are driven to a competitive attitude when they meet a skilled person.

In fact, this attitude produces a natural defensive reaction on the part of skilled people, and the whole thing is not favorable to cooperation

What if, then, the problem is not only with skilled people?

So what if the problem is instead recognizing skilled people and giving them respect?

Domain skills are essential to be able to truly do concurrent engineering and thus develop the products that satisfy a variety of aspects, including environmental sustainability.

Moving from knowledge seen more as an element of power, to the gratuity of sharing, knowing that the return in the medium and long term is much greater requires accompaniment and the example of one’s leaders.

From direct experience, putting 16 cross-functional teams in a position to work well, in tune with stakeholders has been a real challenge, with ups and downs but the balance has been largely positive.

Evolving domain technical leaders to mentors of their staff, lent to development teams, required my special care for them.

Excellent products require excellent teams characterized by people with high skills who are able to cooperate with each other and share their knowledge.

In my opinion, the challenge is to make skilled people cooperate with less skilled people, and I have seen people, the most unexpected and critical, transform and become excellent.

I will return to this topic, which deserves further discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other insights into Agile product development that you might be interested in

Discovery & Construction

Product Discovery Product Construction

I talk to you about innovative product development, inspired by the book “
Inspired: How to Create Tech Products Customers Love ” by Marty Kagan. There is a big difference between leading companies and others in the product creation process. The key concept is “product discovery”: exploring and testing ideas before investing heavily. This is integrated with “product delivery” or “construction.” The author of the book stresses the importance of prototypes, which in HW I prefer to call “pretotypes,” and tools such as Lean Canvas and Story Mapping. There is too much focus on Scrum, when instead it is important to create truly useful functionality. The book is recommended for those who want to truly innovate.

Read More "

The pretypes i.e., the forerunners of the product

Pretypes are quick and inexpensive demonstrators to test key ideas before creating complete prototypes. I am talking about an automated palletizing project where we made a pretotype of the most critical component, which was the tray, in just 15 days. We saved several months and significant investment. This pretotype allowed us to validate the best materials with which to build the final tray.

Read More "

What is the Agile Factory – StoryTime Interview

In this interview with Antonio Panareo of Story Time, we talked about the agile innovation factory that I established during my last corporate experience. Establishing this agile factory was a real gamble and I talk about the experience I had with my teams.

Read More "