How to balance the functional/ cross-functional team seesaw

If you have a few years experience, you have probably experienced or lead several restructures of your teams and organisation. Perhaps, like mine, your organisational seesaw has swung somewhat violently from being primarily divisional to primarily functional and back again, with more than a few participants flying off in the process.

But the truth is that you need to be simultaneously functional and cross-functional. For a software delivery effort with multiple teams, this means you need to support people building successful products while also developing functional excellence. So you need to be good at making sure your teams can stay balanced and do both.

Thinking of this problem like balancing the seesaw, I recommend starting with the heaviest influences and placing them on alternate sides, gradually adding more influence to functional or cross-functional priorities as required. The nice thing is that almost all of the techniques can be applied to either side.

Location, location, location

Because you communicate the most with people in your immediate vicinity, location is the most powerful influence. In my teams, people are seated in a team space that is dedicated to a product or feature, every day they work with other people with different skills and experience to build the best products they can. They focus on their users, developers help write requirements, designers help with testing, support helps with analysis. This works really well, because it means that our products are well rounded, they can be strong in every aspect because the team is.

However, this product team focus is a powerful force, unchecked I could end up with products that are designed very differently, that can’t share components and team members may not learn from what their colleagues in other teams are doing because they see them irregularly.

The manager’s influence

So, to balance the powerful influence of sitting with people building the same product for the same users, I have chosen to make my primary reporting structure functional. Developers are managed by development leads, designers by senior designers and so forth. Managers and the people who report to them are unlikely to be in the same product team. This has some great benefits, more experienced professionals can coach and improve the performance of the professionals who work for them. Team members can ask their managers for guidance, assistance and advice.

Despite the fact that this reporting structure is a powerful force, I found its influence to be insufficient. So my next step was to add some more functional influence.

Facilitate communication

While team members have regular communication with their functional manager, it is overwhelmed by the intensely collaborative environment of a cross functional team space. What I did was to start facilitating more regular communication between team members in similar functions across the teams. To do this, I followed Spotify’s lead and instituted guild and chapter meetings.

Now, developers and devops engineers working on our platform regularly discuss issues, improvements and upcoming work with other developers and engineers in different product teams. Front-end developers and designers discuss the creation and maintenance of our style guide and the building and sharing of common components.

Balanced configurations

The pattern I have used is the one above, cross functional location, functional management, functional communication. However, it isn’t the only model that will balance. I don’t see any reason I could not feasibly have cross-functional teams reporting to product managers and meeting regularly, balancing that influence by sitting each functional team together without functional management.

Unbalanced configurations

Beware the unbalanced configurations, and there are some common ones. One manifests itself as engineers sitting with all the engineers, managed by engineers, this is usually identical for design, testing and every other functional group. This is usually accompanied by a cross-functional project manager, hopelessly lacking in influence, trying desperately and unsuccessfully to bring together people from separate teams in occasional meetings to ‘get alignment’.

Another one I have seen is cross-functional teams, managed by project managers, sitting separately from each other. All seems quiet and peaceful as the teams build wildly divergent products. This is when you end up with one product built with .Net and the other built with Java. In this scenario, your teams build the same thing multiple times and fail to harness the collective power of a large organisation.

The final pattern I have seen is the corrupted implementation. Its the failed upgrade of the organisational world, where an incomplete restructure applies to some parts of teams or some teams and not others. You end up with teams working for functional managers who also manage a product and other teams working for project managers without functional leadership. This is too common, it is a disaster and I would suggest restoring your structure from backup.

Keeping your balance

I prefer to reduce complexity where possible. But, in order to simultaneously balance building great products and functional excellence with a large team, a certain level of complexity is necessary. By being aware of the balance of your team and the influence of different techniques you should be able to achieve both.