Continuous Learning in Cross-Functional Teams

Multipliers and Community of Practice

Continuous Learning in Cross-Functional Teams

An agile approach involves cross-functional teams where individual team members complement each other’s skills. With the move to cloud-based development, teams must often deal with increasing complexity and must learn quickly. Both aspects bring up new challenges when it comes to growing the necessary skills. This blog introduces some problems in empowering the teams to deliver value with quality while keeping a maintainable and testable codebase.

Profile of a Team Member

In this section, we’ll explain the different types of team members in terms of skills profiles. These categories are rather theoretical but can help explain the challenges found in teams:

·        T-shaped team members have deep knowledge/skills in one or several areas as well as a broad base of general supporting knowledge/skills. If this team member has more than one deep area of expertise, you might call these members M- or E-shaped.

·        Generalists have broad skills/knowledge but lack deep expertise in any topic that is important for the team. 

·        I-shaped team members only have expertise in one area and lack the breadth of skills necessary for working with the rest of the team. 

The different types are shown in in the next figure. The depth of related skills is represented by the vertical bar, whereas the horizontal bar represents a breadth of skills and the ability to apply knowledge in areas of expertise other than one’s own and to collaborate across disciplines with experts in other areas. To achieve that, team members need to possess more than technical skills, they’ll also need business domain knowledge and soft skills like empathy, communication skills, and the ability to collaborate in a team.

Cross-Functional Teams

Cross-functional teams consist of several persons with T-shaped profiles, as shown in the next figure. The breadth allows the T-shaped team member to collaborate effectively with team members or complete work outside of their field of expertise. I-shaped team members tend to lack flexibility and have difficulties understanding how their work impacts others.

The problem of an “it’s not my job” attitude inside the team, where developers don’t take responsibility for anything other than their own work, can emerge. A team consisting of team members with T-shaped skills encourages team ownership of the whole product or solution rather than specific chunks.

Multipliers: Need for Topic Experts in the Team

Not every team member can be a deep expert in every field or be connected to other experts in the company. For example, regarding engineering practices, every team member should have a good understanding of clean code, pair programming, continuous integration, and test automation. Thus, a basic skill level is required for every team member, and the goal should be to grow their skill maturity continuously. Not every developer needs to be, nor can be, an expert in all these topics; they can work on growing the skills of the other team members, motivate others, inspire with new ideas, and solve upcoming challenges in their field.

Need for Community of Practice

Working in a cross-functional team, where each team member has different strengths, can sometimes mean that increasing your depth of knowledge is more challenging than in a functionally aligned organization. Communities of practice can connect team members with similar strengths and levels of expertise. For example, if you’re the only expert for clean code or engineering practices in a cross-functional team, then you won’t have access to colleagues that could help you advance in that area. Communities of practice can help otherwise isolated individuals who share similar strengths come together to learn from each other, develop and share best practices, solve problems together, and advance each other’s knowledge.

About me: I am Klaus Haeuptle an engineer and architect at SAP, the author of the books Clean ABAP and Clean SAPUI5, a coach for agile software engineering and a community servant leader for a large SAP internal grass roots community on improving tools, technologies, practices and culture, with more than 3000 participants from all locations and departments. Views are my own - the content published on this channel reflect my opinion and engineering principles.

Subscription: If you want to get updates, you can subscribe to the free newsletter:

Mark as not spam: : When you subscribe to the newsletter please do not forget to check your spam / junk folder. Make sure to "mark as not spam" in your email client and move it to your Inbox. Add the publication's Substack email address to your contact list. All posts will be sent from this address: ecosystem4engineering@substack.com.

Past Editions: The past editions of the engineering ecosystem newsletter can be found in the archive. You can also provide feedback in the discussion thread.

Sharing: Thanks for subscribing to the Engineering Ecosystem. This post is public, so feel free to share it: