Functional vs cross-functional teams

Everyone (almost) has seen the above diagram. Its the infamous Spotify model. It shows how can you organize tech teams, into cross-functional squads.

So, with this structure, you minimize the dependencies and you increase the speed. At least the perceived speed. This is the proper description.

Why you need to do this? It is simple, you need to do it, to realize the business streams, into the organizational structure, because with this way, you minimize also communication within the organization.

So, each PO (Product Owner) prioritizes the work of a squad, which is responsible of delivering a feature end-to-end. Of course a product is rather big, so you have lots of squads, which consist a tribe.

In addition, you have chapters, which are virtual teams that working on the same craft (aka job family eg. iOS engineers) and guilds, which are cross-tribe chapters.

I will not comment on the fact that the Spotify model, is not used by the Spotify as it is rumoured, but try to understand if this works in practice.

A more traditional structure

As I stated in Lean and Mean, I really want to be the exception on the conway law. I really like, small teams with specialized engineers that know the system they are working on.

So the other approach is called “functional”. An approach that a system is comprised by several components, which are owned by specific teams, thus they monitor and maintain them. In addition, they have a specific roadmap.

Of course this approach creates sometimes excessive communication, which scales like the figure below.

Replace people with components and teams.

But, this can mitigated a lot if you structure the software (aka the teams) properly. Yes, yes it can be done. Imagine twitter (x.com) for example, it operates know with 20% of the engineers and is working really well. Why is that happened?

Because, it seems that 80% of the engineering teams, created value of course, but they had a bad ROI.

Dependencies

Nobody wants dependencies, but the solution is not putting generalist software engineers, to write code here and there, just to deliver feature fast. They will not actually, they will get slower over time. But you will believe that they are fast. Why is that happening?

Because, if you have one owner, you will hear him say: “the team is working on this one”.

Apparently the team is trying to cope with the complexity that a software system has. While trying to do that and support the business, they will add more and more custom code, to solve their needs. No clear roadmap. Nothing.

But the solution is the “chapter” and the “guild”. Really? Does anyone think that these structure work? Only to increase developer happiness and morale.

No real work can be done. Why? Simple. It is the same reason, people want to have the business streams as squads.

In order for something to work in a company, somehow it has to be realised in the organisation.

So, chapters are not, guilds are not. Their performance is not really measured, and noone is going to get a promotion becase he/she is an active chapter member.

Epilogue

I am pretty sure that until now, you will have already realised that I am not a big fan of the cross-functional approach. It is true. Mainly, because I hear it by people that do not want to couple their pay-raise with the delivery of software, of good software. Actually, most of them are not even engineers.

But, I try to be open minded. Some aspects, if applied properly can yield some good results.

This article, did not aim to convince you to do the one or the other. I wrote it to try to articulate my thoughts on the matter and only that.