"Every team needs a role x" can mean two things, either plainly "we need expertise x to make y" or more complicated "if you don’t have role x, you don’t have expertise x". The first meaning is easy enough to agree or even disagree with. The second one is a problem for the cross-functional team, its members and their process.
Teams by role #
If we put together a team based on a set of roles, each member runs the risk of becoming a station on an assembly line. Simultaneously, we open up to further mincing of existing roles because there is more of a one to one relation between roles and expertise; we lack certain expertise unless we have a designated role for it.
As this increases the team size, every role becomes an opportunity to not care about other people’s work and, in turn, the collective expertise. Each one has their area, and collaboration happens on a superficial communication level, not on a level where they are able to do or touch upon each other’s work – where we exchange ideas, solutions and challenge each other. The clearer a role is defined and specialised, the more difficult it becomes to raise the common level of expertise. It gives low incentives for learning outside the individual zones, and any problem with the process is viewed as a communication issue. "We need to improve communication between x and y" and "y needs to be present from the start" are usual symptoms of teams that value a predefined set of roles and process steps.
This is not a cross-functional team, and not cross-dysfunctional either, but a sequential-functional team. It manages to deliver according to a template and what they measure but with unpredictable quality and little ownership and trust inside and out.
Handoffs, making deliveries and speed become more important than the current and future quality of the team and product.
Teams by expertise #
A cross-functional team doesn’t have one set of roles, instead, we gather an adaptable set of people with various expertise and experience that can overlap each other to some extent. Every person still doesn’t need to be present in all stages of a project but are involved depending on their experience, insight and learning opportunities, not their role or title.
The markings of a well-blended cross-functional team are cross-functional people. Not everyone needs to be able to do the same tasks, but we aren’t limited to either working separately or sitting knee to knee to collaborate. It’s more in line with how people are and how processes are done. The teams can be smaller because each individual’s area of expertise and responsibility is bigger and more closely related to what’s being made instead of specialised mince fields.
It’s not a workaround for any actual communication problems, but we don’t have to spend time trying to solve a subpar workflow with communication exercises.
Teams for interfaces #
Most of the communication problems aren’t communication problems, they are people in entirely different roles thinking that they work on the same thing because their work happens to be on the same project. In reality, they are mistaking the software and methods of their trade for their expertise, ending up actively, but unconsciously, working against what could bring the team together.
The goal should be to have most of the team able to work in code. Especially the ones that are supposed to be working directly with the interface. If it wasn’t obvious before, accessibility work has shown us that interfaces aren’t separable into code and visuals – we can’t work without code, and code alone isn’t enough.
Not every team making interfaces needs a UX person, an accessibility person, a writer, a UI person and so on. The expertise, yes, probably most of the time, but there’s no need for one person per item on the list. More than bringing a team forward, it cements a fragmented, sequential workflow where the majority never touches the interface.
Code knowledge makes better interfaces #
The most important people in interface making are still the ones that are capable of building them. Meaning only that more people working with interfaces should work with code; not that it’s limited to one type of role or people coding today.
It means code expertise isn’t an indication of a person’s other abilities, it means a team should be a place where different people together can use and expand their knowledge. It should be centred around code because that’s where the interface lives.