#1
β Why are my cross-functional SW dev teams not effective?
π‘ Cross-functionality is seldom enough for SW development teams to be highly effective.
π Cross-functional teams are groups of people with various specializations who work together to achieve a common goal.
This definition might break Semantic Diffusion but introduces further vagueness to SW development teams.
Given the nature of SW development, it is likely not enough that the team is just a cross-functional one. It should also have overlapping skill sets of team members.
Sadly enough, companies often consider that the opposite is true – they simply cram together individuals with disjunctive skill sets and expect the cross-functionality to do its wonders.
Notorious examples include (but are not limited to):
β‘οΈ developers specialized in frontend-only or backend-only,
β‘οΈ having strictly segregated “frontend tasks,” “backend tasks,” or “QA tasks,”
β‘οΈ “developers are not testing” mentality,
β‘οΈ “this is a development task, and I am QA,” etc.
βοΈ Having an effective SW development team means not just having cross-functionality, but overlapping skill sets of team members as well!
π‘ Fortunately, an SW engineer by definition already has more than enough skills overlapping with other SW engineers, regardless of their specialties.
π‘ Tap into those; unlock the full potential of your SW development team!
#2
β Why are overlapping skill sets within a cross-functional SW development team important?
π‘ SW development teams are a special kind of cross-functional team.
π So having overlapping skill sets is crucial for software development teams.
Developing software is, first and foremost, an exercise in knowledge acquisition. Via trial and error through the software development process, the validated knowledge is accumulated, and as a very convenient consequence, the running software is built.
Accumulating the common validated knowledge across specializations, as well as within them, is of great importance.
Having non-overlapping (disjunctive) skill sets inevitably results in a sort of siloed knowledge; trying to break out of those silos requires transforming the ideas and knowledge before they could be transferred between silos.
βοΈ Such transformations are always degenerative!
π‘ Formulating ideas so they can be transferred from one’s mental model, results in a kind of LOSSY COMPRESSION of data (ideas and knowledge).
π‘ Conversely, trying to fit those formulated ideas into another’s mental model requires a great deal of guessing to fill in the gaps required by receiving side.
In addition, the mental models are bound to be different, so this loss is guaranteed.
π‘ To maximize the quality of ideas and knowledge exchange within the team, ensure that there is enough overlap of knowledge and skill sets.
#3
β My developers claim they are specialists. How can I tell if they have overlapping skill sets?
In order to have a group of individuals with no overlapping skills, a) their knowledge must either be wildly different from one another or b) have an extremely narrow knowledge area or “I-shaped” skill set.
For a group of software engineers, the chances of a) happening are close to zero.
For software engineers, on the other hand, it is unlikely to have such a narrow knowledge area to be considered “I-shaped.” This is something that might be the case for junior students or absolute beginners in software engineering, though, which is most likely not the case with your teams.
βHow come?
Aside from learning the very basics of computer programming, every other concept builds on others, not only accumulating knowledge but widening the understanding. In addition to learning a programming language and/or a framework, there are chances one will learn about protocols, APIs, structures, algorithms, patterns, testing strategies, databases, etc.
This widens the base knowledge in addition to a “spike” in expertise, widely known as a “T-shaped” skill set.
But having a narrow focus on just one particular area is so rare in software development, that most engineers end up with more areas of expertise, resulting in “Ο-shaped” or “m-shaped” skillsets, with multiple expertise “spikes.”
π‘ Instead of yielding to excuses, look for opportunities to harness the knowledge every software developer has in addition to their narrow expertise!
#4
β Aren’t multi-skilled developers a sort of unicorn, i.e., impossible to find?
π As described above, there are different models describing individual skill sets.
The prevailing view is that individuals within SW development teams are narrowly-focused experts, e.g., FE, BE, QA, and such. That describes the famous “I-shaped” individual skillset – narrow expert skills or knowledge, with little to no relevant ones outside the chief area of expertise.
That, of course, assumes that a “T-shaped” skill set leads to unicorns, i.e., developers who are experts in, for example, both FE and BE (and possibly QA.)
βοΈHowever, this is a blatant oversimplification.
π From one perspective, those respective fields of expertise are so expansive that they form their own skill set shapes.
π From another perspective, skill sets are multilayered, so those narrow areas of expertise build on broader, more common areas of knowledge, which lead to building larger skill sets.
Rarely do SW development teams have team members missing basic computer science, general software engineering, or knowledge of widely-adopted practices, patterns, and algorithms.
For example, it sounds reasonable to expect that there are at least various levels of knowledge of business and functional analysis, software design, and varying levels of QA expertise among ALL team members.
π Everything described here provides a required skill set overlaps within a cross-functional SW development team.