Guide to Building Cross-Functional Collaboration In Software Engineering

Guide to Building Cross-Functional Collaboration In Software Engineering - Interview with Ritendra Datta (Director of Engineering, Meta)

If you want to build a well-rounded product, strong cross-functional collaboration is a must.

As a leader, you must make sure that cross-functional partners have empathy towards each other and that they understand the value of other functions. 

Ritendra Datta, Director of Engineering at Meta, gives valuable advice on improving cross-functional collaboration. He shares his viewpoint on cross-functional collaboration, talks about common mistakes when leading or scaling cross-functional teams, and offers a possible solution to keep good morale within cross-functional teams. 

This blog post was written based on episode 67 of the Level-up Engineering podcast hosted by Karolina Tóth. 

This post covers:

• Roles in cross-functional teams
• Engineers
• Cross-functional partners
• Collaboration around different types of software
• Cross-functional collaboration in practice
• Hierarchy in cross-functional teams
• Triad of leaders
• Developing products
• Blurry roles
• Encourage cross-functional collaboration as a leader
• Inclusion
• Resourcing
• Transparency and self-awareness
• Encouraging respect during cross-functional collaboration
• Understand the problem
• Hold cross-functional empathy sessions
• Cross-functional collaboration through empathy sessions
• Encourage autonomy
• Spot malintent
• Common mistakes during cross-functional collaboration
• Large meetings
• Lack of representation
• Trust issues
• Scaling cross-functional teams
• Right reasons to scale
• Scaling in small vs. large companies
• Involving management in growing cross-functional teams
• Keep the boat afloat
• Pick the captain first
• Numbers don’t always count
• Scaling problems at large companies
• Hiring leaders in-house vs. outside the company
• How to choose the right manager
• About Ritendra Datta

How do cross-functional teams work?

The role of engineers

Engineers and research scientists build new products. They write algorithms and code while creating the necessary systems for product development. Everyone else surrounding them is a cross-functional partner with their particular responsibilities.

The role of cross-functional partners

• Product managers collaborate closely with engineering and VPs.
• Data scientists build machine learning models in some companies, while in others, they give insights from data to support engineering.
• Data engineers build pipelines and help data scientists and engineers with their work. 
• Product or UI/UX designers talk to people to figure out what features engineers should build into the product.
• Product marketing managers are the liaison between products and clients.

Consumer vs. enterprise software 

Different types of software require different types of engineering methods, so in some cases, cross-functional collaboration is more important than in others. 

With consumer software, it’s easier to gather insight. For example, if your team works on a social media platform’s software, they’re most likely consumers of that product, and so are their families and friends. They know which features need to be improved or changed, because they use the product on a daily basis as consumers. 

If you’re working on enterprise software, however, you’re unlikely to be your own customer, so you’re more reliant on the expertise of your cross-functional partners’ research and insight.

What does cross-functional collaboration look like in practice? 

Cross-functional hierarchy

In cross-functional teams, there is a hierarchy of managers and leaders, all the way up to VPs and CXOs. The reporting structure of the company affects how they collaborate with each other. Each leader has a clearly identified counterpart, for example, an engineering manager has a product manager counterpart. 

Triad of leaders 

Product managers, engineering managers and senior ICs often work together as a team, and they are the base of cross-functional collaboration. This triad of leaders is the most critical set of people in the product development process. They keep close contact with the UX designer, the UX researcher and the data scientists through the product manager. 

Product development process

Every product is born from an idea. In a bottom-up culture, this idea can come from anywhere: an engineer, an IC-level product manager or a data scientist.

The product manager determines the minimum viable product by writing a PRD and creating a roadmap. They also have to consider factors such as privacy and security measures as well as the available resources before bringing the idea to the engineering team. 

The planning and decision-making parts are bottom-up, but then the refined plan and the roadmap is presented to a senior leader for approval. The first version may not get approved. In those cases, a VP or a senior director looks at the plan and gives advice or asks for clarification. It’s important to get a senior’s insight and approval before executing a new idea, because people at higher levels tend to have wider information about markets, timing and budget.

Agile companies sometimes reverse this process: they try something out immediately, then gather data about it. This way, they can see what’s working and what needs to be iterated, and they can set a new direction if necessary. 

Software is never done. It’s frustrating and exciting at the same time, but there’s no sharp ending to a project, because some features can always be improved. 

Blurry roles

In an ideal situation, the lines between cross-functional roles are blurry. 

A product manager might come up with a good engineering idea. An engineering manager might have a strong product sense. An IC might develop an entrepreneurial mindset, and bring up product ideas.

If you hire well-rounded employees, they can act in their assigned role 80% of the time and contribute to other cross-functional roles in the remaining 20%. That way, everyone feels included in organizational decision making, and cross-functional collaboration will be stronger. 

What can leaders do to encourage cross-functional collaboration?

Focus on inclusion

Cross-functional collaboration can only work if you have the right leaders who make sure that people feel empowered, included and heard in key decision making forums. Feeling left out or excluded does not support the culture of a collaborative cross-functional group. 

People have opinions, and they want to be part of the conversation early on. Each function and each individual brings a unique perspective, which can be invaluable in the long run. If you only include one function for the majority of product development, you won’t have a well-rounded product.

Practice smart resourcing

It’s hard to determine how much work a particular cross-functional partner needs to finish a project, especially if they’re not included in the conversation. They can’t plan early on, so they’ll become overworked in the late stages. 

Be transparent and self-aware

Learn more about what others do around you. Conflicts happen within cross-functional teams when there isn’t a transparent flow of information and understanding. Get close to people on your team, understand what they do, and it will help you become a better leader. 

We tend to judge others quickly. Be self-aware of that, call yourself out, and correct your mistakes along the way. Learning about other people's leadership stories can also help you reflect on yours.

How do you make sure everyone understands and respects other cross functions?

Understand where criticism comes from   

With cross-functional collaboration, it’s inevitable that people in one function criticize others in other functions, questioning how they are contributing to the final product. It can lead to frustration and conflicts. 

It’s common for ICs to not see what their skip level managers do on a daily basis. It’s also common for engineers to not see the value of product managers or data scientists. It roots in their biases; they focus on their own work, and believe that anyone who’s not doing the same is useless. 

It’s a problem of inclusion. Just because you don’t see somebody else’s contribution, it doesn’t mean that they’re unnecessary. 

Cross-functional partners don’t criticize each other for the sake of bullying; it happens because they lack information about the value the other functions bring. This is a serious problem, but it can easily be solved.

Cross-functional empathy sessions

We have cross-functional empathy sessions, where people get together for 4 hours and represent all cross functions. The key tech lead, an IC, a manager, a product manager, a data scientist and a UX researcher will meet somewhere outside of the office, and spend the day talking to each other.

They could discuss what they do on a daily basis, and what’s frustrating about it. The representatives of each function gain a better understanding of the different positions, and why the work of each function is valuable and challenging in its own way. 

Every time we have these cross-functional empathy sessions, everyone goes home humbled by what others are doing and the struggles they’re facing. They realize that everyone is working hard. They often describe it as “an eye-opening experience.” 

Example: The importance of a UXR

A good example is a UXR. Many tech companies are data-driven, running A-B tests and almost blindly picking one variant, thinking people like it more. But sometimes this data doesn’t capture the emotions that the product is intended to evoke.

That’s where UX researchers come in. They can get more accurate measurements of success, and they can tell if A is preferred by users, even if the data on B looks better. It’s because the metrics used by engineers can’t caption emotion, and so, you can’t rely solely on this information without consulting a UXR. 

How are cross-functional empathy sessions conducted?

Encourage autonomy

Empathy sessions work best if cross-functional teams recognize when they need one, and they take the initiative to organize it. Usually, the engineering leader and the product leader counterparts team up: They decide that they want to do an empathy session, and then they notify upper management about the plan. 

Reject malintent

Empathy sessions aren’t useful if there’s malintent within the group. If people are miscommunicating, or if they lack empathy and aren’t open to changing their minds, it doesn’t make sense to hold the session. 

Avoid these conflicts by encouraging people to hold cross-functional empathy sessions at least every 6 months, so they’re constantly reminded of the value that other functions bring to the project. 

How to spot selfish intent

Large companies are driven by promotion culture, and that can lead to selfish intent. If some leaders are solely focused on their personal career growth,  it doesn't always lead to the right decisions. 

It can also be true for other cross-functional partners.

They might take on projects not to  serve the company, the product or the users, but to serve their own career. It can hinder the goal of empathy sessions as well. They will question what they are personally getting out of participating in these events.

This happens more within a function, among peers. You’re less likely to compete with a cross-functional partner for a promotion, but you might fight for scope on projects with your peers. Empathy sessions are useful in these cases, too: people can share their frustrations with each other, and their manager can help with separating their responsibilities, so they won’t compete with each other for the wrong reasons. 

What are common mistakes when trying to build cross-functional collaboration?

Overcrowded meetings

Don’t put too many people in a meeting unless it’s a one-sided conversation where someone is disseminating information. For other types of meetings, keep it under 10 participants. 

One principle you can follow is to include the right decision maker for each function in a meeting. You don’t need anyone above or below them in the reporting chain just to make them feel good about being invited. People can be enthusiastic about meetings when they don’t have too many of them - don’t overbook their calendar, only include them when necessary, and they’ll look forward to those meetings. 

No representation

People might fear that not being part of a certain meeting means they’re out of that conversation. This is another mistake to look out for. Provide the right communication channels, have the right leaders present, and they will figure out a way to forward the information for their team while representing them at the meeting simultaneously. 

Lack of trust

Those who aren’t invited to a meeting that concerns them must trust that they’ll receive relevant information. They shouldn’t assume that important details will be hidden from them to someone else’s advantage. If that’s the case, you have a bigger problem to solve than the number of people in meetings.

When should you scale cross-functional teams? 

Know when to scale

There’s a cynical view of scaling — some leaders scale their teams for the sake of building an empire. You must scale for the right reasons, when there’s work to be done. 

When your product is scaling, you may need to scale your team with it. If there are more requests coming in, if there’s bigger demand to improve multiple features in a product, the number of cross-functional teams needs to grow.

As a leader, you must make sure that scaling doesn’t feel like unnecessary growth within the company. You can grow your team, but do it if you have the right indications that it’s necessary for a better product that has already found product-market fit. 

Growth isn’t the answer

It’s better to have a smaller team that can effectively prioritize than to have a large team that’s doing redundant work. Multiple teams working on the same project is bad for morale. Engineers recognize that somebody else is working on the same piece of code, and they will either get frustrated with the redundant work, or they’ll worry about their job being unnecessary or replaceable. 

You can always fill the room

A different approach to scaling is to see it as switching to a larger room. A bigger room can hold more air in it, just like an upscaled company can always find enough work to do. This philosophy can work in some cases, although it’s the opposite of keeping teams lean to avoid redundant work.

Scaling: Startups vs. large companies

With small startups, it’s easier to keep teams small, because they can’t afford empire building yet. 

For large companies, scaling is trickier. It’s difficult to track how many people would be enough. Those who make decisions during hypergrowth often have to decide without having all the necessary information, and they resort to making guesses and deal with the aftereffects of bad scaling decisions later. 

How do you involve management in the scaling process?

Keep the boat afloat

Scaling while managing the already existing workload is like being in a boat with your team. Your team is growing the boat in size and capacity while it’s moving, and you make sure they don’t fall into the water. The boat moves fast, but everyone is protected.

Pick the captain first

Scaling needs the right leaders. There are different ways to make sure you have the right people leading your cross-functional teams. Some companies hire the top leaders of the industry, and give them a charter of growth. When you approach scaling from the other way around, and hire lots of new people before bringing in leaders and managers, it tends to be more challenging. 

If you pick the leaders first, they are with you throughout the scaling process, and they learn a lot more. That way, you build a bench for your ship, so if you fall sick or go on vacation, these leaders will be able to take over. Key leaders not having proper substitutes means that the company has to run on autopilot for a while, and larger organizations cannot operate like that.

Don’t focus on numbers

When hiring managers, they often inquire about the number of people they’re going to manage. That’s challenging, because it might be their top priority, but you might not be able to answer that. 

It’s more common that leaders want to run a large team from day one, but some of them are happy to take on a charter and grow it along the way. Scaling is more effective in the latter case, but these types of managers are harder to find.

Scaling at large companies

Scaling policies differ at each company, and it depends on how involved someone’s role as a manager is. If you work at a company where you have a lot of work to do per team member, you tend to have fewer direct reports. Other organizations can have managers with 30 reports, and they have fewer responsibilities per engineer. 

Is it better to hire an experienced leader for scaling or do you prefer promoting leaders internally? 

Both solutions are equally common.

The tricky part about making one of your engineers a manager is that now they become the manager of their peers, and sometimes, that doesn’t land well. 

In some industries, becoming a manager is a career leap. In the tech industry, becoming a manager isn’t necessarily a promotion. Maintaining an IC role can be just as valuable. 

How to decide

When there's a need for a highly technical manager, it’s a great idea to hire internally. If you want to find your next manager in house, there are a few traits to look for in potential candidates.

Empathy

The most important skill a manager has to master is leading with empathy. Does this person have enough empathy for the role?

Humility

Do they like the idea of not getting credit for their work directly? Are they happy to give credit to their team? 

If there’s a senior engineer who masters both of these leadership soft skills, you have found a new manager who can contribute to scaling and perfecting cross-functional collaboration within the company.

About Ritendra Datta

Ritendra is a Director of Engineering at Meta, and has been there for three years. He runs the Facebook video and reels recommendations teams. Before that, he worked at Google for ten years, where he went from summer intern all the way up to leading 30 engineers as a tech lead manager. There, he founded, led and managed teams working on shopping searches on Google. 

He is passionate about building scalable systems. Aside from engineering, he loves making films.