There’s no such thing as “technical” people
If you’re involved in public sector digital work, you’re probably familiar with the notion of the cross-functional team.
A cross functional team is united by the goal of delivering a product. It might contain developers, designers, user researchers and business analysts, collaborating on the same work.
The idea is that with a mix of expertise, the team will start thinking about user needs in the same breath as technical limitations, and deliver a better product, sooner.
This is quite different to the traditional waterfall style, where you might organise teams by specialism, each one throwing their work “over the wall” to the next.
It’s closely allied with the idea of T-shaped people — that is, staff who have their specialist area of expertise, but can also draw on broad exposure to and knowledge of other areas.
But we often struggle to build truly cross-functional teams in practice.
Building a resilient team
Let’s say your cross-functional team has four people: a tester, a developer, a user researcher and a product owner.
Normally, work might be planned out by the user researcher, built by the developer, checked over by the tester and signed off by the product owner.
But let’s say your user researcher suddenly quits, or goes on leave, or has to spend time on responsibilities elsewhere (say, recruitment).
Work will start backing up and the product delivery schedule slips.
The team isn’t resilient.
In our fictional example, you could resolve this by hiring more user researchers, but let’s say the product isn’t big enough to merit two full-time user researchers. One of them will spend a lot of time doing nothing.
A better approach is to make sure that your team is cross-functional enough that the other team members can pick up the slack if someone isn’t available. Perhaps that means a business analyst substituting for the product owner, or the product owner taking notes in a user research session.
It’s tough enough to get teams to embrace this “everyone gets involved” attitude, but even in those that do, the role of the developer is seen as sacrosanct.
The downside of “professions”
We like to build communities of practice across departments and teams, so that people playing the same role on different products can learn from each other through mailing lists, events and mentoring.
These communities are incredibly valuable, but end up being formalised in the HR concept of a “profession” — a framework of common job roles and responsibilities. If a community of practice is a living, breathing thing, a profession framework is the taxidermied, stuffed version.
Once people start relying on profession frameworks to decide what particular team members should and shouldn’t be doing, we’ve taken a big step away from being cross-functional.
All roles are technical
If pushed, many people will put themselves into either a “technical” or “non-technical” box.
Developer, engineer, tester? You’re Technical™. User researcher, designer, business analyst? You’re Non-technical™.
This is a false distinction and only serves to create factions and silos within teams, where the “non-technical” people don’t understand what the “technical” people are up to, and vice versa.
Crucially, it blocks “non-technical” people from helping build the product and limits their potential.
Every job is technical one one way or another. Writing good code is no more specialist than insightful user research. Thinking otherwise is a disservice to all those “non-technical” skills.
Make no mistake, overcoming this distinction is a massive task. I’m not suggesting that every team member should be writing an equal share of the code, but as long as developers are seen as untouchable rockstars, teams won’t be resilient and products will suffer.
