The importance of crossing the disciplines

When you're part of a "modern" software building team, changes are, it is being referred to as "multi disciplinary" or "cross functional". This is to indicate that the team is made up of backend developers, frontend developers, some design role(s) and maybe somebody in charge of metrics and KPIs or some additional, specialised roles.

The thought process here is that if you do that, the team can be completely in control of their responsibility (maybe add some DevOps terminology in there then, as well). Which makes for agile teams.

This is usually fine and dandy when you're in a relatively small environment, since lines are short and by default you are in close contact with your team mates as co workers. It doesn't always scale well though, this concept. Imagine 10+ teams which work for the same organisation. Sure, within the teams' setup, there's still a common goal, but now there are more factors at play: you have to cross align certain goals between or across teams. You need to roll out a uniform branding. Maybe you're dependant on APIs from another team.

Communication channels increase exponentially as employees increase (Sandoe, 2001)

For every team or discipline that's added to an organisation, there's an exponential increase in communication channels. That escalates quickly and is anti scalable!

I've also seen smaller agency like companies fall into this trap, where little margins create a desire to rapidly waterfall through the traditional steps of creating a website or app.

To combat this, companies start to adopt something like the Spotify model in some form or another. Which makes sense right? You want to facilitate those communication lines. Organisations form chapters, tribes and other cross team groups to align on the common ground between those members, which is usually technology based.

That's where things get hairy, because it starts to shift to alignment and communications from what was originally aimed at facilitating a teams' needs and goals, to whatever is on the radar for a certain domain. It takes time and focus away from the team!

As a result, since we're all creatures of habit, I've seen that the alignment on technology level starts to supersede the alignment on domain level. When the communication within a team starts to decline, you are dangerously close to creating small waterfalls within your teams. Which I've seen happening in multiple organisations on several occasions.

By these small waterfalls I mean that processes move one way, with little upstream feedback or communication. This is tempting, but on the long run less efficient than the more agile approach most companies strive for. Where the obvious reasoning is that: software is complex and it is impossible to foresee all complexities before you start a next phase.

In time, this means that the original idea of having a cross functional team, is not providing the value you would expect and could (in worst case scenarios), lead to friction within a team.

As the teams working at Spotify will tell you: the Spotify model is not set in stone. It is constantly changing and also being adopted to the users' needs. So please don't go around creating tribes and chapters if you have no need for them, treat it as inspiration rather than gospel. (Even if you Google for the "Spotify Model", Spotify itself is very absent of the results.)

The core principle should still be to enable those teams in optimal communications within the team. The alignment on tech should just play a supporting role. Make sure that your designers, developers and business analysts stay on the same page and are working together instead of passing down work to each other. This is what I mean with crossing disciplines. Keep crossing those boundaries, because that's how you can co create to build amazing stuff.

Let your designers cultivate an understanding of what the purpose of a microservice is and allow your backend developers to understand performance from a UX point of view, rather than a metric measures in ms. In the end, what you're building is always reliant on multiple factors and disciplines to be successful. The most successful solutions come from teams who have a common understanding of each other strengths and purpose.