Structuring Cross-Functional Teams

Problem

In a previous role, my work with my team was very domain-specific. We were supporting manufacturing, so there was a lot of work that interacted directly with hardware and the people operating that hardware. This meant that if you knew what you were working on, you really knew it inside and out. Coming from a different product would leave you without quite a bit of domain knowledge in the area. You couldn’t really read it from the documentation.

We had to divide ourselves into two new, smaller teams. I had too many people reporting to me directly, and the group was becoming difficult to manage effectively. This prompted the question: when splitting up the group, what would be the best way to draw these dividing lines?

We wanted to increase visibility across departmental lines, to give our employees insight into what the rest of the company was doing and to retain these hubs of knowledge within each team. Splitting our team up allowed us to find a healthy level of transparency.

Actions taken

One team would be working with me in our office, and the other would be communicating with us remotely from another office. We had scaled fairly quickly, and I wanted to make sure that our needs in the future would be accounted for. I started to think about the best way to structure both of these teams sustainably.

One thought was to build a self-sustained, full-stack team on both sides, two teams that would be more or less equal and that would be able to do similar things. This approach has obvious benefits.

The other thought would be to build a small horizontal layer. One team is responsible for a certain product area. One team picks up where the other team leaves off. In the end, we adopted a hybrid model. Each team had an emphasis area, and the team was not entirely interchangeable, but able to step into each others’ roles if needed temporarily.

In terms of team composition, you’re likely working with a lot of different people who all have different skillsets. Most of our people were software developers, but some were not. We grouped these folks together and put a manager on top of them to provide any context that fell outside of their domain. The other team consisted only of hardcore developers who reported directly to me.

The goal was, over time, to have these two teams work together to inform one another as we progressed. After a year or so, they started to cross-pollinate as we continued to bring more people on. This efficient solution fed into what we had and allowed us to evolve to that next step.

Lessons learned

• People in other industries may be more people-driven than process- or Jira-driven. Keeping this in mind may help you solve any problems with them that you encounter and help you support them with your work.
• We were able to help both teams further their skillsets through their interactions with one another. We needed our non-engineers to know that their support was very important to our objectives.
• As companies mature, they may sometimes move away from this model. This is because they may need that deeper level of domain expertise as their product evolves.