Structuring Cross-Functional Teams
13 July, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Angel Jamie, Chief Product Officer at Yayzy, recalls his transition from a well-established tech company to a sustainability startup, and the major differences he experienced.
CPO at yayzy
Rachit Lohani, Head of Engineering at Atlassian, shares all his ideas and principles on providing feedback and avoiding discomfort while doing so.
Head of Engineering at Atlassian
Joëlle Gernez, Vice President, Engineering at Pinger, shares how she built great relationships with her direct reports and broke the vicious cycle of poor one-on-one meetings.
Vice President, Engineering at Pinger
Joëlle Gernez, Vice President, Engineering at Pinger, shares how having visibility on the processes that engineering teams work on is crucial.
Vice President, Engineering at Pinger
Jason De Oliveira, CTO for more than 10 years, shares his experience completing a reorganization, implementing agile, and collaborating with multiple teams.
Jason De Oliveira
CTO at Kolquare
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.